Loading ...
Sorry, an error occurred while loading the content.

Re: Centralized v. Decentralized Source Control (Re: [XP] web development source control)

Expand Messages
  • Chris Wheeler
    ... Although he is the typical use-case for nerds getting beaten up in high school - I ve never heard an intelligent talk from this guy, but I have heard
    Message 1 of 36 , Oct 3, 2007
    • 0 Attachment
      On 10/3/07, Adrian Howard <adrianh@...> wrote:
      >
      >
      > I'm not sure Linus's situation is a typical use-case for most folk
      > though :-)



      Although he is the typical use-case for nerds getting beaten up in high
      school - I've never heard an intelligent talk from this guy, but I have
      heard plenty of talks telling me I'm stupid for not seeing things the exact
      same way that he does. One of the most disrespectful people in the industry.

      Chris.


      [Non-text portions of this message have been removed]
    • Kim Gräsman
      Hi Leonard, Thanks for the exhaustive info! - Kim
      Message 36 of 36 , Oct 17, 2007
      • 0 Attachment
        Hi Leonard,

        Thanks for the exhaustive info!

        - Kim

        On 10/18/07, Leonard Chin <l.g.chin@...> wrote:
        >
        > I happen to be a new git user, from svn. Even ignoring its distributed
        > advantages, git really shines as a "source control management" system.
        > Even when using it as a local repository as the sole user, git still
        > outshines svn.
        > - git is faster than svn
        > - tagging "works" - you actually tag an individual commit in your history.
        > - merging "works" - svn merge is a coarse-grained (you collapse the
        > differences between trees into a single commit), where as a git merge
        > will retain the individual commit histories of the branches being
        > merged.
        > - the built-in command line tools are very nice (viewing colored logs,
        > diffs, etc)
        > - git tracks content, not files -- so git can automatically detect
        > when a file's name is changed, or when you refactor and move lines
        > code within/between files
        > - file integrity - git makes sha1 hashes of everything, so you'll know
        > if your files have been corrupted
        > - you can "cherry-pick" a single commit from a different branch to merge.
        > - there is no need to "prepare" a base directory layout of branch/trunk/
        > - using git bisect, you can find the exact commit that introduces a
        > bug via a "binary search". Start with a known bad and good commit,
        > check the "middle" commit, and repeat. This is useful if, say, a big
        > merge introduces a bug/failed test, and works because merges preserve
        > history.
        > - Continuous integration becomes easier because, you merge committed
        > (i.e. saved) changes instead of committing unsaved changes.
        >
        > Using git-svn also makes git very compatible with svn. Effectively,
        > you can use git-svn as your own offline client for subversion.
        > http://utsl.gen.nz/talks/git-svn/intro.html
        >
        > There are some minor disadvantages, though:
        > - windows support is poor. It is really built on unix. Cygwin/colinux
        > partially solve this, though.
        > - the paradigm shift from files to content is big - in cvs/svn,
        > everyone is used to tracking individual files, and not the changes to
        > the content. Git isn't designed this way, so tracking the lifecycle of
        > a file is more expensive, and there are no partial checkouts. However,
        > I don't think such features are relevant anymore.
        >
        > However, I am very happy with git. I see absolutely no reason to "go
        > back" to subversion.
      Your message has been successfully submitted and would be delivered to recipients shortly.