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.
Git set and aid esr for cvs and svn fix. HTH.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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.
He isn't raising new money, he's opening up a discussion on what to do with the remaining money in some fund he started, and he said he'll match what's currently in the fund.
Wish we could talk the editors into doing basic fact checking on the article submissions they allow through.
The allergies are so bad this year that the drug dealers are turning meth back into Sudafed.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
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.
ESR has already helped several free software projects convert from CVS to Git using his existing computer. The bigger the project, the longer it takes. (Each attempt to convert the Emacs repos takes 8 hours with his current computer.) He has studied the C code for doing the conversion, and determined that the best sort of computer for doing these conversions would be as fast as possible (doesn't matter how many cores; this is a single-thread process) and would have as much RAM as possible. Graphics card? Whatever, who cares. Keyboard, mouse? Not going to buy those, he already has those. Oh, and he would prefer it not sound like a leaf blower so he is looking for quiet power supply and a case with large quiet fans.
He says that several people spontaneously donated money to help him buy a better computer. So he opened up a discussion for how to best spend the money.
Several people urged him to only use ECC RAM, which means either an AMD chip or a Xeon. Someone just donated $1000 (!!!) so he has pretty much settled on the Xeon.
Once he has this, he will go around to free software projects and offer to do the conversion for them. His plan is to grab a copy of the CVS repo, run the conversion to make sure there are no surprises, then ask the project maintainers to stop modifying the CVS repo while he runs the final conversion.
This seems like a reasonable service for him to be offering. Instead of each project figuring out the conversion process, he will become an expert on CVS to Git conversions (with more experience than anyone else) and he will have the purpose-built computer to do the conversions as quickly as possible. So he really will be saving time and hassle for the various projects.
P.S. He converted the NetHack repos, and stirred up a hornets' nest. Read about it here: http://esr.ibiblio.org/?p=6389&cpage=1#comment-1207141
lf(1): it's like ls(1) but sorts filenames by extension, tersely
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.