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

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

Expand Messages
  • David Bourgeois
    ... There s a Google tech talk from Linux Torvalds about Git, with plenty of arguments against subversion as it appears he simply hates it:
    Message 1 of 36 , Oct 3 12:56 AM
      >> Other good reasons?
      > Google around for "Decentralized Source Control" and you'll get some
      > fine arguments :-)

      There's a Google tech talk from Linux Torvalds about Git, with plenty of
      arguments against subversion as it appears he simply hates it:

    • Kim Gräsman
      Hi Leonard, Thanks for the exhaustive info! - Kim
      Message 36 of 36 , Oct 17 11:37 PM
        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.