[svlug] Preventing a Revision Control Flamewar

[N.J. Thomas]

* Rick Moen <rick at linuxmafia.com> [2008-10-19 16:11:37+0000]:
> svn also cannot handle file renames at all: Instead, you get delete
> and re-checkin, such that the new file loses the old file's history.

As someone else in this thread pointed out, svn does file renames while
preserving history just fine -- and this has always been the case (i.e.
there has never been a time when "svn mv" did not preserve revision
history).

What Bram Cohen or the commentator you refer to might have been talking
about is the kludgy way in which Subversion does it. "svn mv foo bar" is
equivalent to "svn cp foo bar; svn rm foo".

Whether or not this is really a kludge or is a technically correct way
to do renames is something I'm not terribly sure about.

> My own attitude is that, if you're going to go to the trouble of
> learning a new VCS, it might as well be a truly superior one in all
> sorts of ways (git, Hg, bzr)

I like the decentralized-repository feature of the new generation
revision control systems. I also really, really, like how blazingly fast
git is.

I'm not at all happy with how git forces me to copy the entire
repository when all I wanted to do is a simple checkout and commit
though. I've heard that some other RCSs can do both a clone or a svn-style
checkout, not sure if git has that feature yet though. Also, git's
interface to me seems unnecessarily complex (but I'm not an expert on
it).

To me, the perfect RCS system would:

    - be decentralized
    - have the simplicity of the Subversion interface
    - be fast like git
    - be able to do a clone (a copy of the repository) or a checkout
      (only a working copy)
    - preserve file timestamps (nobody does this for whatever reason)

Thomas