Slashdot Mirror
Help ESR Stamp Out CVS and SVN In Our Lifetime
mtaht writes ESR is collecting specifications and donations towards getting a new high end machine to be used for massive CVS and SVN repository conversions, after encountering problems with converting the whole of netbsd over to git. What he's doing now sort of reminds me of holding a bake sale to build a bomber, but he's well on his way towards Xeon class or higher for the work. What else can be done to speed up adoption of git and preserve all the computer history kept in source code repositories? ESR says he'll match funds toward the purchase of the needed hardware, so if you want to help drive him into bankruptcy, now's your chance.
Nice trolling, dice.
TFA is about killing CVS for Git. It says NOTHING of SVN. This is probably because SVN is still a decent system and Git is no replacement (and the reverse is also true).
CVS should die though, yes. Move to SVN or Git depending on your particular needs.
Like the so called "death of the mainframe", the death of CVS is still a long way off. From a business POV moving a large well managed CVS repository to something else is simply not worth the effort in most cases. I look after CVS repository for ~25 devs, some of the (active) code has been there for well over a decade. We looked long and hard at git, the benefits are not enough to justify turning the whole shop upside down for a few months. Physically converting the repository is just part of problem, there's also the automated build and tracking scripts that depend on CVS. You can also add to that the down time for at least half the devs to learn the new system - it's quite disturbing how many experienced devs only have a marginal understanding of source control in the first place.
Of course if you're starting a new repository then use the shinny new hammer with the rubber grip.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
If Git did all that SVN does, I'd be glad to switch.
But there are capabilities in SVN that Git not only doesn't have, it has decided it will never have. And that's a problem.
Biggest issue for me? In SVN, I can create an extern to a subdirectory of a project. Git's subprojects always point to the root of a project. And for us, that's a big deal.
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
Agreed. SVN just works. It's a very standard model that many source code control systems use. I think 99% of source code control systems have one of two methods:
- check out files explicitly which locks them, then unlock when you check back in.
- don't check out files then when you check them in it tries an automatic merge if necessary (this part is prone to failure, even on git, never trust an automatic merge without verifying it).
The big variants between them all is in the details. Ie, SVN and Perforce have change sets (all files checked in succeed or none of them do). Or the amount of headaches to go through when creating branches. Or how much effort in administration there is.
Git is great for what it does and was designed for: a distributed system where all of the developers are in remote locations and never talk to each other in person and don't work for the same company (ie, typical open source). That does not mean it's automatically the best solution for ever possible project.