[slime-devel] CVS and friends

[dherring at tentpost.com]

Helmut Eller wrote:
> * dherring at tentpost.com [2010-08-23 15:54] writes:
>
>> FWIW, Subversion was written because CVS has several well-known flaws
>> which can result in a borked commit leaving the repository in a
>> completely
>> inconsistent state.  SVN was designed to be a drop-in replacement with
>> atomic commits to fix the fundamental issues in CVS.
>
> VCS debates...  everybody has heard all the arguments already a dozen
> times and the result will be the same.  Let's face it: it's a waste of
> time.

...


>> Speaking from experience, newer tools including DVCSs *can* interact
>> with
>> CVS; but their users must give up most of the new features in doing so
>> (including all the distributed features), and the conversion process is
>> quite fragile and painful (largely due to CVS's lack of atomic commits).
>> It is not a pleasant experience.
>
> I don't understand what you mean.  The point of those DVCSs seems to be
> that you don't need a central server and that every clone/repository has
> all the history and therefore supports *all* features.

Only true if each DVCS user has the same history.  Since CVS is
fundamentally broken, there are dozens of fuzz algorithms that try to
extract a history.  This is a nontrivial task, the conversion routines are
not as well developed as other tools, etc.  As a result, people intending
to check back into CVS or SVN are advised to do their own conversions and
not share with others.

I tried sharing converted repos.  It was a massive maintenance drain, and
eventually failed spectacularly.  Everything needed a total rebuild once a
year or so, each time the conversion tool changed substantially.  Not fun
at all.  Lesson learned.  Any conversion, even something saner like darcs
to git, is fraught with terror.


>> A switch to SVN means basically changing "cvs command" to "svn command".
>> The newer tools with vastly superior history models do have different
>> command sets.
>>
>> IMNSHO, there were no justifiable reasons for using CVS in 2005, much
>> less
>> in 2010.  The choice of VCS has ramifications to end-users and potential
>> developers.
>
> Well, Emacs switched from CVS to Bzr a while back.  For someone like me
> who essentially only needs "cvs up" once in a while the switch was a net
> loss.  What used to take 2 minutes and downloaded 5 MB with CVS takes
> now 20 minutes and 200 MB.  My urge to update is no pretty much zero.
>
> I doubt that it was an improvement for real Emacs developers either, as
> the main topic on the emacs-devel mailing list is now (since 6 month or
> so) in how many ways Bzr sucks.  Good use of resources that is.

At least we can agree that Bzr sucks.  ;)

Seriously, I'm no SVN fanboy; but an upgrade from CVS to SVN causes
minimal user-visible changes, while fixing some rather substantial bugs in
CVS.  It is like changing from rsh to ssh -- there are almost no
downsides.

I only have CVS installed for a handful of projects.  Sadly, they are all
CL projects...

- Daniel