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

Umm, what?

[Anonymous Coward]

What is this? Who is ESR? Why is he/she/it supposed to be a household name around here? What is this (presumed) being's claim to fame?

After getting that prerequisite out of the way, following the links -- which are all to the same guy's blog -- what is the purpose here? It sounds like some rogue guy who wants to fork every project using CVS or SVN and stick them on Github or something. What's the need for this? Why should anyone care? That was all quite absent from any of the reading material provided.

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

[Anonymous Coward]

First of all, SVN didn't "clobber" your working copy. You aren't working alone! That means that others will be making changes to the same code base that you're making changes to. If your changes don't directly overlap, then everything is perfectly fine. You can do an update, and it will bring in their changes without affecting yours.

Now if you modify the same parts of the files that others have modified, yes, you will run into conflicts. That's a good thing! SVN forces you to deal with them right away, which is always the best time to deal with them. If you put off merging to later, like is often done with git, you're in for a world of pain.

If you were running into conflicts 80% of the time, it isn't a problem with SVN. You or your team is probably doing something idiotic, like having all of the source code in a single file, and organizing it so that two developers working on separate functionality end up interfering with one another. If that's the case, then it doesn't matter which source control system you use. You'll run into the same conflicts.

You're just deceiving yourself when using git, by the way. Since you're just using your own local repo most of the time, you don't run into a bad merge until much later on, when you go to push the changes to another repo (or some other user goes to pull your changes). This is when git falls apart, with disastrous merges. Just follow any moderately-sized open source Ruby or JavaScript project's mailing list, and you'll see what I mean. Every day there are people complaining about problems merging in changes when using git, and the victim is told to rebase constantly.

SVN is good because it makes you deal wtih conflicts immediately. Git is bad because it delays dealing with conflicts until days, weeks, or even months later, at which point it all goes to hell.

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.

Horrific Summary

[Anonymous Coward]

Do you expect anything else from timothy?

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.