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.
You had my curiosity, then I read this:
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.
Now you have my attention.
(Not enough to RTFS however. This is Slashdot...)
Jesus was all right but his disciples were thick and ordinary. -John Lennon
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.
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.
Sig: I stole this sig.
I just want CVS to stop giving me so much shit when I try to buy up all their Sudafed.
I'VE GOT A *BAD COLD*, ALRIGHT?!! THAT'S WHY!!!!!
SJW's don't eliminate discrimination. They just expropriate it for themselves.
Oh come on, TFS isn't bad enough to be flamebait!
Now, VSS, on the other hand...
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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.
I'm more concerned about CVS. Where am I going to get my prescriptions filled?!?
Yo dawg, I heard you like CVS so I put your pharmacy's dyslexic tabular data in version control.
...or something like that.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Git is the best repository because it's the easiest to insult when something goes wrong. "Stupid git!" is a lot better than "Stupid CVS!"
Not a sentence!
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
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.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Do you expect anything else from timothy?
VSS (Visual SourceSafe) was okay - as long as you locked it up behind a SourceOffSite (3rd party) server. The SOS service as the primary interface between the VSS repository and the clients prevented about 99% of corruption issues.
This was back when your options amounted to VSS, Perforce, and a few other high priced version control systems. About the only free solution back around 2000 was CVS, and that was just bad for other reasons.
(Some teams benefit from distributed version control systems like Mercurial/Git. Others benefit more from centralized VCS like SVN / TFS / Perforce. We prefer SVN because it is far easier for non-technical members, i.e. mere mortals, to understand and much harder for them to do the wrong thing.)
Wolde you bothe eate your cake, and have your cake?
My fucking monitor went tits up, and probably due to blown caps, you insensitive clod!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
He was a nutbar way before that, I assure you. I had my first runs into him in the first half of the 90's. The Cathedral and the Bazaar remains his single shining moment.
Also, easier to buy Sudafed (or Meth) from drug dealers than to get Sudafed from a pharmacy.
Clearly then, the next generation version control system should be named "Sexy Flanders".
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
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
There are many usecases where people will need a centralized version control system (VCS). SVN was written ground up to be best in class centralized VCS and they accomplished this goal while building a very elegant and efficient client server framework to boot.
However IMO, SVN is still missing one very important feature: obliterate. This is a huge weakness with large repositories.
I also missed branch aware meta data in the early versions (I've been using since 0.8x) and not sure if this has changed. Git has done a very good job there.
After going through the process of moving from VSS to Subversion here some 10 years ago, I am in no hurry to change source control again.
We had to educate a whole bunch of people, many of whom had never used anything more sophisticated than a tarball for version control, on how to use subversion.
Much as I like DVCS, and in hindsight it would be useful to have some form of it here, it would have to:
1) Be able to import our large and complex codebase,
2) Cope with the fact that we have one repos with multiple projects, each with multiple code modules, each using (for some reason) non standard path names, not trunk/branches/tags, but Trunk/Branches/Releases.
3) Be easy to learn and tolerant of mistakes, so probably Mercurial rather than git
4) Integrate with our home grown automated build system that resolves dependencies, records svn version info in headers, and ties in with at least 3 different build environments.
The barrier to entry is now too high - we have tried twice now to jump it, even tried to rework the svn2hg scripts, but have not found a solution that wouldn't stope us working for over a month.
Sigh!
.
Am I the only one concerned about the resulting monoculture if the GIT proponents have their way?
CVS should die though, yes. Move to SVN or Git depending on your particular needs.
My particular needs are to (1) check out only a subset of files, because those files are binary and very large, and (2) permanently delete those files that I know I will no longer need. Unfortunately, neither SVN nor Git meets those needs, but CVS does. (And as much as I like SVN, rebuilding the entire repository doesn't count for (2)).
You don't buy expensive, power-hungry [hard]ware that's going to cost an arm and a leg to store, power, and cool for the next year when you only need its brute force for a few hours.
But he is planning to do conversions over and over, one after another, handling problems as they occur. As such, one of his goals is that the conversion be as speedy as possible, and he specifically said that he doesn't want to share a CPU with other cloud users. He wants one fast CPU devoted 100% to his project.
Makes sense to me.
The Cloud isn't a magical cure-all, but it's a perfect fit for things like this.
The cloud would be a pretty good fit for projects that wanted to do their conversion one time. But an even better fit would be one guy doing a whole bunch of projects, one after another, with a fast hardware. And that's the plan.
I switched to Afrin (oxymetazoline spray) over all this sudameth hysteria. It's notorious in some circles for being "addictive", meaning withdrawal after prolonged use produces rebound congestion, but use in one nostril at a time minimizes that.
I stay away from those dangerous drugs. There's nothing that a bottle of vodka and a Steven Seagal movie marathon can't cure.
lucm, indeed.
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.
(2) permanently delete those files that I know I will no longer need.
I'm confused. The entire purpose of an archive database is to KEEP things, forever, so you can go back to them when you need to. If you have files that you expect to delete, maybe they shouldn't be going into the database.
No you're not; you're being patronizing. I am a photographer. I take lots of photos. The negatives are over 30 MB each. A single day's shooting can be dozens of GB. And while I expect to delete many of them, I don't know which of those will be deleted until I've gone through and worked with them. But I want them in an archive immediately, so I can have them tracked, versioned (the XMP sidecars/DNG headers are plaintext), backed-up, remotely accessible, etc.
The funny thing is, despite pretentious boosters of one modern VCS after another arguing that their lack of a feature is a feature in and of itself, and that I'm stupid for having different needs than them, ancient CVS does *exactly* what I need it to do. (Proprietary Perforce is even better, though I'd prefer something open source). So until its competitors catch up with its state-of-the-art 1990's technology, I'm going to keep using CVS.