* dherring@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.
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.
Helmut