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

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

Expand Messages
  • Adrian Howard
    ... Because I m working with N other people. ... Nope. Nothing like that built into SVN. There s limited support for synchronisation with svnsync, but nothing
    Message 1 of 36 , Oct 2, 2007
    • 0 Attachment
      On 1 Oct 2007, at 18:23, Kim Gräsman wrote:

      > Hi Adrian,
      >
      > Sorry for the late reply.
      >
      > I thought this technique sounded incredibly cool, and decided to try
      > it some time. I told my colleagues about it, and one of them asked:
      > "Why not just set up a local SVN repository?"

      Because I'm working with N other people.

      > Good question... I should be able to merge between different repos
      > with Subversion, right?
      >
      > SVK can "replay" my commits using --verbatim, but Subversion doesn't
      > have that ability as far as I know?

      Nope. Nothing like that built into SVN. There's limited support for
      synchronisation with svnsync, but nothing like the flexibility
      something like SVK (or git or whatever distributed system you choose)
      gives.

      > Other good reasons?

      Google around for "Decentralized Source Control" and you'll get some
      fine arguments :-)

      Adrian
    • 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.