[svlug] Preventing a Revision Control Flamewar

[Brian J. Tarricone]

On Sun, 19 Oct 2008 16:11:37 -0700 Rick Moen wrote:

> Quoting Bill Ward (bill at wards.net):
> 
> > Anyway based on all the input I've heard, I'm leery of DVCS and
> > don't really think any of them would quite suit my needs.
> 
> Centralised client/server operation a la CVS/svn/ClearCase/Perforce is
> actually something that any DVCS _can_ automatically do, because all
> you need do is eschew the DVCS's innate ability to do local commits
> and local branching.  So, being more comfortable with the centralised
> checkin model logically shouldn't rule out DVCSes.

No, but there's certainly a little marginal extra work involved.  In
git parlance, you have to commit and then push every time you want to
check something in centrally.  Of course, a simple script would fix
that.

> It stores snapshots rather than changesets, shapshotting being the
> worse of the two alternatives as a long-term architectural choice,
> though the nature of the error only becomes apparent as you start
> thinking of doing branching and merging.

... probably not an issue for Bill's use case.

>  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.  (OTOH, git punts on file
> renames, too.)

Nuh-uh.  SVN has supported preserving history across renames for a very
long time now.  I just tried it myself to be sure, and it works fine
(using 'svn mv').  A 'svn log $newfilename' after the move shows the
history of the new name followed by the history of the old name.

Your comment about git is correct, though, unfortunately.  While the
file's history is maintained both pre- and post-rename, seems to be
that you need to use the old file name with 'git log' to get history
before the rename (and annoyingly, you need to do 'git log --
$oldfilename' so it doesn't try to interpret the file name as a
branch/commit/whatever name).

> 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), but svn's perfectly OK for what it does,
> and any VCS is better than none.

In a general sense, sure, but if you don't care about VCSs for the sake
of VCSs, might as well just pick whatever seems easiest and best suited
to the job and go with that.

	-brian