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.
This is ESR we're talking about, and then there was the line about wanting to drive him into bankruptcy.
How many of the comments are going to be the same old attacks on him?
TLDR: inb4 haters.
Equivalent Series Resistance?
I don't want to do a sig now
Sounds like something to do with medicine and pharmacy.
Yeah I know RTFA TL;DR yada yada
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
Save-On -> Longs Drugs -> CVS -> ESR
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"?
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.
I use mercurial, you insensitive clod!
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.
And whatever shall we do with the bathwater now that the baby is gone?
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.
gah.
Seriously, what does he care what repository some other project uses... I know various people have experimented trying to shoehorn the NetBSD repository and history into Subversion, Hg, and git over the years and they've always ended in failure... So far CVS is working even though it's not super awesome. But at least it works. Why should NetBSD switch to something that can only barely work from something that's already working.
I'm sure I'll get flame-broiled because I'm not wanking my pud over Git.
P.S. PRSVP or STF, because NAWE are SAaD
excitingthingstodo.blogspot.com
I love git as much as the next nerd However, many centrally-managed hierarchical orgs do just fine with an SVN workflow. Something distributed like git or hg feels very alien to them. Forcing them to accept a workflow that grates against how their organization works is just inneficient. Just because a lot more people work on distributed teams in very different environments than the predominant environment 10 years ago doesn't mean that this group's toolchain is best for everyone
Get it on the cloud.. Grab a box, spin it up, convert that CVS then spin it down.. You can save money with the config by first spinning the box as a micro instance.. Cost you maybe $50...
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.
Not sure why he needs to buy a new machine (CapEx) when this task seems a good match for OpEx solutions.
You can get a lot of CPU hours for $700....
Not sure why he would be asking for donation anyway - contracting and writing not paying much ?
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.
ENOUGH ALREADY!!
A few hours ago, I learned that I am now (at least in theory) absurdly rich.
He's asking for money, but does not say why the transformation needs to occur.
But what about all my SCCS repositories?
TFA is about killing CVS for Git. It says NOTHING of SVN.
Sorry Charlie...
Do you expect anything else from timothy?
It's very important that all the bits are converted into different bits on a server that he keeps in his bedroom. This is important because ESR is an alpha male, and the bits can tell if they've been converted on a machine maintained by a lesser mortal.
Also, he's asking for a donation because he didn't become absurdly rich by writing checks.
and fuck this article
Should be raising funds to improve git so that it can get the job done on reasonable hardware.
I've done a couple big conversions like that now, and the whole process is crazy painful and multiplied by the network timeouts and svn checkout churn required to get it done.
Even if it could just run in the background for a week and could resume from error, that would be something.
Another approach might be to put a git protocol fake front end on these things.
Flame ON!
CVS should die though, yes.
Yes CVS should die. this is why I stuck with RCS.
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.
SVN is fine, there is no reason to throw it out and migrate to the flavor of the month. I'm just fed up with the current direction of taking anything and everything that works and throwing it out for a new rewrite of the same old thing.
I think I was there too! The old Linux Expo sponsored by Red Hat?
Yes, you would expect a bandwagon person like ESR to hate SVN because it's the cool thing to do now. I haven't heard a single rational argument against it yet. Even Linus, who is normally rational, acts stupid when it people question him about it. He should be able to back-up his claim, but he never has.
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.
> NC Biotech Center in 1998.
That was actually in April 1997. I was there when ESR got thrown out of the bar because the bar tender though he was retarded. He wouldn't sell alcohol to him. I think the fact that ESR was ranting about guns was more the reason he was thrown out. If his position on Subversion is as irrational as it is on guns, then I would expect him to hate it because Subversion makes sense and simply just works for people.
What the fuck is wrong with Subversion?
Hosting Git is dirt cheap. Converting from ${old_terrible_system} to Git is the painful one-time expense. Here's how you do it:
1. Fire up a suitably bit AWS cloud server.
2. Copy your repo to it.
3. Run the command to convert your old repo to Git.
4. Download the new Git repo.
5. Shut down the instance.
You don't buy expensive, power-hungry software 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. The Cloud isn't a magical cure-all, but it's a perfect fit for things like this.
Dewey, what part of this looks like authorities should be involved?
It's rather fitting that when talking about CVS you pretend the cloud doesn't exist and that purchasing a big-ass box to sit on your desktop is even remotely reasonable for the suggested workload. It's not like it's 2014 or anything.
I've already created perl scripts to do this. I've already got the blob files and a full git repo for netbsd. Yes, it takes days for these to run but what's the big deal?
I did this because I needed the scripts to convert some of my old personal software from CVS/RCS to git. To debug the scripts, I thought that a true test would be to convert something massive like netbsd. I'm not a snob as I also configured for freebsd and openbsd but didn't run the scripts on those.
I did this on an old 8-core 2.5GHz 64 bit machine with 12GB ram [and 120 of swap space] and enough disk space. The full retail price on this was $3000 five years ago. The same specs can be had much cheaper today.
How many repos of what projects are going to be converted? 10? 100? 1000? Ultimately, there aren't enough projects to justify a machine for 100% usage for a five year period.
I tried to post the script here but various /. posting filters tripped over the 800+ lines. So, here's the top comment section along with the comments for the various functions:
# gtx/cvscvt.pm -- cvs to git conversion
#
#@+
# commands:
# rsync -- sync from remote CVS repo
# cvsinit -- initialize local CVS repository
# co -- checkout CVS source
# agent -- do conversion (e.g. create blob files)
# xz -- compress blob files
# import -- import blob files using git-fast-import
# clone -- clone the bare git repo into a "real" one
# git -- run git command
#
# symbols:
# cvscvt_topdir -- top directory
# cvscvt_module -- cvs module name
# cvscvt_agent -- conversion agent (e.g. cvs2git)
#
# cvshome -- top level for most cvs files
# cvscvt_srcdir -- cvs work directory
# cvsroot -- cvs root directory (CVSROOT)
# cvsroot_repo -- cvsroot/CVSROOT
# cvscvt_rsyncdir -- cvsroot/cvscvt_module
#
# cvscvt_blobdir -- directory to store agent output blobs
# cvscvt_tmpdir -- temp directory
# cvscvt_logdir -- directory for logfiles
#
# git_top -- git files top directory
# git_repo -- git repo *.git directory
# git_src -- git extraction directory
# git_dir -- git [final] repo directory
# git_work -- git [final] working directory
#
# cvscvt_xzlimit -- xz memory compression limit
#@-
# cvscvtinit -- initialize
# cvscvtcmd -- get list of commands
# _cvscvtcmd -- get list of commands
# cvscvtopt -- decode options
# cvscvtall -- do all import steps
# cvscvt_rsync -- sync with remote repo
# cvscvt_tar -- create tar archive
# cvscvt_cvsinit -- create real repository
# cvscvt_co -- do checkout
# cvscvt_agent -- invoke conversion agent [usually cvs2git]
# cvscvt_cvs2git -- run cvs2git command
# cvscvt_xz -- compress blob files
# _cvscvtxz -- show sizes
# cvscvt_import -- run git fast-import command
# cvscvt_clone -- clone the bare git repo into a "real" one
# cvscvt_git -- clone the bare git repo into a "real" one
# cvscvt_cvsps -- run cvsps command
# cvscvtblobs -- get blob files
# cvscvtshow -- show cvs2git results
# cvscvtshow_evtmsg -- get fake timestamp
# cvscvtshow_etarpt -- show amount remaining
# cvscvtshow_msg -- output a message
# cvscvteval -- set variable
# cvscvtexec -- show vxsystem error
# cvslogfile -- get logfile
# cvslogpivot -- rename logfile
Like a good neighbor, fsck is there
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
What's the first thing you do when you encounter trouble, hipster? You call men with guns to help you, but you think that their costumes imbue them with magical gun-handling prowess.
SVN works just fine. I see no need to move our corporate version control to git. GIt is fine of your doing a world wide project like the Linux kernel - but there is absolutely no to use a distributed version control in an enterprise. Git is fine for world wide open source projects, People should be free to use whatever they want - isn't that the whole idea behind open source? Heck if someone wants to use RCS - go for it - why should I care.ESR is just starting a war of version control. IF he wants to use git - let him, if we want to use SVN that's our prerogative.... git is just Napster for source code.
The Truth is a Virus!!!
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!
> What he's doing now sort of reminds me of holding a bake sale to build a bomber
OP speaks as if he witnessed this before
So is ESR trying to convert the NetBSD CVS repo in some weird and special way or something, and that's why it failed? Because it has already been converted and is on Github; if he needs info on how it was done, there's probably someone on the tech-repository mailing list that can help. It's been converted to Fossil too.
> git done right.
I agree 100%
www.fossil-scm.org
Aphorisms don't fix code. (Bart Smaalders)
SVN works just fine. I see no need to move our corporate version control to git. GIt is fine of your doing a world wide project like the Linux kernel - but there is absolutely no to use a distributed version control in an enterprise.
Then you don't understand distributed version control. If you have more than 1 programmer you have a need for distributed version control.
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)).
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.
What kind of butt drugs are you on?
1. He started the OSI to shoutdown the FSF, divisionism fucking idiot
2. He seems to do more talking about software than he does actually writing it.
3. I get a feeling he's also somewhat responsible for the lolbertarian trending equating capitalism to rights, that we saw in the 1990s. No wonder he hates stallman, who isn't anti-capitalist, but thinks that rights exist independantly of economic systems.
Can't happen: he'll have more limited choices of what to masturbate with, which would never work with an ammosexual like ESR.
I eventually got submodules to work properly for me, and have been using them effectively (I think) for a few years now. But it's not easy teaching other devs. Which is why I need to spend some time investigating hg properly. Although you can do sparse checkouts with git, apparently hg has some plugins which allow you to partially clone a repo without necessarily cloning all of the objects in its history (supposedly plugins can fetch that on demand, rather than in the initial clone). It seems this is possible because git is designed around a data format, whereas hg is designed around an API. It all seems great but I just can't find the time to invest in hg
I like Git, but it does not scale for large projects where the repo size is greater than 1 gigabyte. It doesn't work for binary files well if they're large. Git may improve over time, but it's not the same.
Oh I dunno about that... we (thankfully) haven't heard much from/about him here in many years, and when he does actually turn up again it's for writing some bit of software.
17GB? Maybe you should not put binaries in your source code repository.
lucm, indeed.
(1) check out only a subset of files, because those files are binary and very large, and
Git can do this with sparse checkouts, but as you probably know, neither git nor svn are really meant to manage large binary files. You'd do best to use a repository that was designed to fit your needs so you're not constantly butting heads with your version control system.
(2) permanently delete those files that I know I will no longer need.
Most source code version control systems are specifically designed to avoid permanent data loss, so again, you're going to fighting your VCS if you use one that was meant to handle source code. That being said, BFG will permanently delete data from a git repository if that is necessary for whatever reason.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
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.
It's just that ESR has an old decrepit machine to do it on. A low-end Xeon w/16-32G of ECC ram and, most importantly, a nice SSD for the input data set, and a large HDD for the output (so as not to wear out the SSD), would do the job easily on repos far larger than 16GB. The IPS of those cpus is insane. Just one of our E3-1240v3 (haswell) blades can compile the entire FreeBSD ports repo from scratch in less than 24 hours.
For quiet, nothing fancy is really needed. These cpus run very cool, so you just get a big copper cooler (with a big variable but slow fan) and a case with a large (fixed, slow) 80mm input fan and a large (fixed slow) 80mm output fan and you won't hear a thing from the case.
-Matt
> Why would one in his sane mind convert from CVS to SVN?
Because Subversion really is "CVS done right". It scales much, much better, it's much easier to administer and manage, and it has much better support for large centralized repositories with limited access to specific parts of it for specific developers. My transformations from CVS to Subversion have been quite straightforward, except where developers manually edited old CVS files in the repository itself and broke things years previously.
If you need the local flexibility and to have source control access when disconnected from your central repository, the 'git2svn' interface has also been invaluable.
I read through half the comments here before twigging to what's really going on. He's got all of $700 for this project. And we're paying attention to this because???
(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.
If by large you mean tens of megabytes. Downhill, with a stiff breeze at its back.
Compared to the code you'll find in a CVS or SVN these days, the VCS itself is the leadt of your problems.
that not a single person here has posted a single reason as to why they think SVN is bad. You are correct about it being "irrational hate."
It is high time eric goes back to the 90s and leaves real programmers alone. Doesn't anyone else feel at least a little ashamed of how this guy who gave us the fetchmail plague always grabs the limelight ? The same guy who is notorious for harassing women at conferences and for generally being a nutbag.
I for one am going to create a whole bunch of SVN repositories now, just because.
"Only one thing is impossible for God: To find any sense in any copyright law on the planet." - Mark Twain
Fire up an amazon cloud instance configured for number crunching, do conversion, shut it down again. This shouldn't cost more than 50 bucks...
"Only one thing is impossible for God: To find any sense in any copyright law on the planet." - Mark Twain
If you like the paradigm of the centralized repository which sure has it's uses then consider moving to SVN instead. It will make things easier and nicer, it is CVS done right.
The git/mercurial crowd just cannot stand the CVS/SVN workflow and wants a lot more flexibility which makes perfect sense for a global open source project. If you don't need all that, move to SVN and be happy.
"Only one thing is impossible for God: To find any sense in any copyright law on the planet." - Mark Twain
(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.
You'd do best to use a repository that was designed to fit your needs so you're not constantly butting heads with your version control system.
I'd love to know if such thing exists (in an open source form, ideally). As far as I'm aware, no such thing exists. (Boar is getting close, however, so I'm hopeful).
Anyone remember when ESR was known mostly for providing us with esoteric knowledge? Now he's known for spouting, and making bad decisions. This is one of them. Git is shit for the casual user. It might be the greatest thing since sliced bread for the hardcore developer who does massive merges, but for everyone else it makes life worse and not better. You can't resume a fetch, and you can't fetch a subdirectory. That means for example that I literally cannot work on Android-x86, because my rinky-dink internet connection cannot handle fetching the git repo. Or if it can, I never found the magical collection of switches that would do it. And I shouldn't have to hunt. There should be one command which fetches the current version, and none of the history, and there should be another command which fetches the history, and then there should be a command which does both. And all of them should have clear and obvious names, and there should be examples for each in the EXAMPLES section of the man page. Anything less is defective versioning software.
Git is shit, and anyone who says different is selling something. In this case, Linus is selling himself the lie that he didn't fuck up when creating git's UI, and ESR is reselling it... also to himself. If your tool needs massive documentation, then your UI is shitcakes.
The fact that git is shit wouldn't be such a problem if projects would still publish tarballs, but most of them aren't doing that any more, because they're relying on git to provide that functionality.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
No VCS is meant to do this, neither Git, SVN and certainly not CVS. Those files don't belong in a VCS because you cannot make a diff between them. Small binary files (e.g. icons in a website) are a small nuisance, but there is no point in storing large binary blobs in a VCS regularly. What you need is a backup system, not a version-control system.
SVN allows to do this with svndumpfilter (and I was unaware CVS had any way to do this). And no it should not be made any easier, no one should be allowed to monkey around with the repository history with any less than admin rights. If you find yourself regularly removing files from a VCS, it means you have been adding too many useless files. Again, you want backup for this, not VCS.
Victims of 9/11: <3000. Traffic in the US: >30,000/y
If you're a photographer dealing with 30MB images, then you're almost certainly using non-destructive editing on them. It sounds like the tool that you want is not a version control system at all, it's a filesystem.
I am TheRaven on Soylent News
Seriously, if they are archiving the source code to Duke Nukem, then surely they can archive the NetBSD Source tree?
Heh. It IS a feature in the use case for which it was designed. Making it work the way you'd want it to would break the original use case.
If a train station is a place where a train stops, what's a workstation?
The best solution is Alienbrain, but if you were looking for open source, then you probably don't have budget for Alienbrain.
There are other solutions that can probably work for you, but I'm not sure which ones support easy permanent deletion of assets, as that is not a use case that I've ever encountered, personally. But at the end of the day, if CVS fits well with your workflow, there is no point in you changing to some other solution just because CVS is fundamentally defective as a source code version control system.
You're not using it for source code, so CVS's basic architectural flaws don't necessarily apply to you. If it's the best tool for your job, then use it in good health!
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
...and I actually understood the headline. Oh well, that's what you get for being old.
Single threaded processes don't necessarily need the latest generation processors because they just keep adding cores. Instead of trying to buy a new server, why not just accept a donation of a 3ish year old dell/hp/supermicro server. Lots of businesses & universities have a hardware rotation cycle for really good hardware. I've bought perfectly good poweredge servers that were a few years old for under $50 before at a university computer auction.
Well, ...
we both did not get it.
ERS wants to transform SVN to Git and CVS to Git
Regarding your experience ... welll, In my experience SVN is a pain in the ass in large organizations ... especially it is slow like hell.
30 minutes synchronization and commit times are common.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
In fairness, at one point in the discussion ESR did say he had converted a few SVN repos for free software projects. But the joke about "stamp out... in your lifetime" was only applied to CVS AFAIK.
The part about ESR wanting to transform large public repositories to git, I understand. I only meant to explain why someone would want to take the original step of transforming a CVS repo to Subversion.
I was unaware CVS had any way to do this
CVS is just a layer on top of RCS. RCS stores all history for a given file, in a file in the RCS store named for that file.
Therefore to purge all history for that file, you delete it's repository file. Tada! Gone.
CVS is just a layer on top of something designed for single file programs, and it shows. It doesn't handle renames well. It doesn't handle getting arbitrary revisions of entire projects well. The more files you have in your project, the more overhead you'll consume attempting to track global project revisions.
SVN does at least fix some of that.
Sorry, I realize that could have sounded patronizing, but I didn't mean it that way. I really think that it's a question of the tool fitting the purpose. *All* of the archive systems I've ever worked with have been designed to *prevent* deletion, accidental or intentional, because they were designed to work with text and documents. (And since you brought up the word, I feel compelled to point out that I did not suggest that you're "stupid" for having different needs, just that maybe it's the wrong tool for your purpose.) Heck, if CVS is doing the job you need done, and you are careful not to destroy the wrong things, then by all means keep using it.
How easy would it be to create different repositories? Then you could save a day's shooting in a short-term repository until you had at least reviewed them, at some point copy over the ones you want to keep to a more permanent repository, and delete the whole short-term repository - admittedly crude, but much less work than rebuilding.
My apologies for my overly combative response. Thank you for your kind clarification.