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.

Comments

Doesn't say SVN in TFA

[Anonymous Coward]

Nice trolling, dice.

I am not going to convert

[ModernGeek]

I might do it for some things, but right now the ability to only checkout a subdirectory[source] is paramount in the way we use svn around here. Nestled with the fact that there are so many git solutions that are third-party hosted only, and so many hostable open source subversion options available, I'll stick with svn.

Moving everything to the cloud, which is marketing speak for someone else's servers, for increased functionality is not an acceptable solution. Sure, you can host your own git repository, but the functionality in the available F/OSS solutions blows.

Re:I am not going to convert

[gbjbaanb]

Exactly. I don't know why there's such nerdage against SVN except that git is hard, so therefore its better somehow. Despite the fact you can lose your history (irrevocably if you try) and screw things up even if you don't.

If something is working, there's no point in trying to break it. And if you were to go break it, you'd go with Fossil anyway, git done right.

Re:I am not going to convert

[Darinbob]

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.

About CVS Only! Not SVN!

[Anonymous Coward]

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.

Counterpoint

[Tenebrousedge]

Git's subtree / subproject management is extremely painful. The information manager from hell, indeed. I dislike SVN/CVS extremely, but they make much easier to do sub-repositories. For example, Arch's ABS is entirely under SVN, which works well enough for them, but using git the same way sounds like torture.

Re:Horrific Summary

[Lunix Nutcase]

That would require the editors to be as literate as a five year old. That's just a cruel requirement.

If it works, leave it alone.

[TapeCutter]

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.

If Git did all that SVN does...

[jdege]

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.

Git Is Not The Be All End All

[Dredd13]

I wish people would stop pretending that the DSCM model is the "only way of the future". There are plenty of completely valid use-cases for monolithic source control models. For instance, I am a firm believer that configuration management repos belong in a strictly monolithic architecture, with a single source of truth, deterministic version numbering, etc., etc....

Certainly I could see a case for moving people from CVS to something more modern (but in the same basic vein) like SVN, but here's the thing:

If their existing SCM application is working for them, and they're happy with it, then it's perfectly fine.