[svlug] Preventing a Revision Control Flamewar

[Rick Moen]

Quoting Brian J. Tarricone (bjt23 at cornell.edu):

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

{shrug}   Trivia.   The main point is that the DVCS model is a proper
superset of the centralised one, a point I mention because people
freuently misunderstand it and erroneously think centralised development
is impossible or difficult with a DVCS.

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

They might have finally fixed that when I wasn't looking.  I noted the
analysis on this point by one of the better commentators -- possibly
Bram Cohen -- who pointed out that, at the time, the svn people had been
claiming for quite some time to version renames, and that the claim was

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

A very short-sighted attitude, and I note that you similarly ignore my
point about the reasons for favouring tools that enable major advances 
(and thus are generally superior) even if you have no immediate need for
the advantages.  You blandly observed that those long-term advances are
irrelevant to Bill's usage case.   Oh well.