Help ESR Stamp Out CVS and SVN In Our Lifetime 245
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... (Score:3)
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...)
Re:You had my curiosity... (Score:4, Funny)
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 a bad way to go out if you think about it. Assume ESR in his doctor's office: "You have three months to live."
"Cool! I'm going to instigate a full on crapfest buying spree fueled by my "GeekNation." We'll pre-order *everything* Intel, Foxconn, and Cisco are going to produce in the next two decades, I'll be long dead once the bills start to roll in, and Western Civilization will collapse into a black hole of insolvency before anyone realizes what's going on. Suck it PRC bastards! I'll be bigger than Hitler!!! Woohoo!"
<Dilbert>Was that better or worse? I don't know how to tell.</Dilbert> # PHB: "You don't show enough passion for your job."
[A bit over the top, I admit, but we are discussing ESR.]
Won't this alphabet soup ever end? (Score:2)
Repository or suppository? (Score:2)
3-letter challenge (Score:5, Funny)
Git set and aid esr for cvs and svn fix. HTH.
Doesn't say SVN in TFA (Score:5, Insightful)
Nice trolling, dice.
Re: (Score:2)
I am not going to convert (Score:5, Insightful)
I might do it for some things, but right now the ability to only checkout a subdirectory[source [stackoverflow.com]] 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 (Score:5, Insightful)
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: (Score:2)
Despite the fact you can lose your history (irrevocably if you try) and screw things up even if you don't.
Probably not, everything in git can be undone (except something like rm -rf * .* but your repository can be restored even then if you have a backup).
Re: (Score:2)
the trouble with DVCSs is there is no repository to backup. Everyone has their copies and a vape in one can (and will) be propagated to the others. Restore your repo from backups and watch as someone then commits the vape when they push their changes to you - the system doesn't know that it shouldn't take that commit.
Its not like a centralized system where you can have proper backups.
Re: (Score:2)
Re: (Score:2)
Despite the fact you can lose your history (irrevocably if you try) and screw things up even if you don't.
The only way to lose history irrevocably in git is if both of the following two conditions are met:
Most people do push to a central repository, so condition #1 is usually not met. And mucking about in your .git directory is not a normal use case, either. You should use the git comma
Re: (Score:2, Insightful)
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, whic
Re:I am not going to convert (Score:5, Insightful)
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.
Re: (Score:2)
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.
I really don't get the argument why limiting my own options would be something good. If things "go to hell" for you because you don't merge/rebase often enough, then do it more often! There is nothing inherent in Git preventing you from using the SVN workflow. It is even the default behaviour if you just work on the master branch and do pulls.
In fact, I would argue that Git is actually much better than SVN in the respect of dealing with a moving target, since you have the rebase feature. With SVN, you eithe
Re: (Score:2)
Unless you're ok with a source control system that's trivially capable of throwing away history and corrupting your entire repository irreparably [...]
I don't get what you people are doing to corrupt your repositories, or even "throwing away history" (whatever that means). To me, it sounds like saying "A bicycle is better than a car, in case you run yourself over with it". To really lose stuff in Git, you have to really try to deliberately shoot yourself in the head, or be such an insane klutz you should be let anywhere near a computer with write access to a central repository anyway.
[...] all for the sake of making your history log "pretty".
That is because you think of the revision history as a chronological "tr
Re: (Score:2)
You've never worked in fifty-person contract software houses, have you? With the way that world works, you have no choice but to often work on the same files. There's *actually* no way around it. (You can imagine how terrible things were back when we were using VSS with mandatory lock-and-checkout semantics.)
I'm sure that many of us have worked in much larger development environments than this. When every developer in the offices pulls out every thing in the repository and tries to check the whole repo in after modifying the 1-2 files they changed, that is the problem.
Personally I blame management in this case, since they are hiring and not training and/or supervising the staff properly.
Having worked with both, and being mostly operations, I prefer git myself. My coding is mostly operations tools, and I don't
Re: (Score:2)
That causes zero issues in SVN, because in SVN it only commits the files that have changed... now, if you have a developer editing dozens and dozens of files and doing a massive commit, that's a separate management issue. (i.e. they should be doing a feature branch)
Where SVN falls down is in complicated branch/merge scenarios,
Re: (Score:2)
you can have a pop at SVN for many things (hell, you can have a pop at anything for the same reasons) but seriously, you're trying to use those arguments?
SVN's security is like all the others, except for servers like VIsualSVN that implement active directory auth. Its not unstable at all, more people complain about it not being more bleeding edge, but of course its job is to be stable. They updated to serf, 3 years ago? and there were issues in the betas. Whoop, what did you expect.
And the 'philosophy' that
Re: (Score:2)
We just converted from CVS to SVN about three years ago, so it's too soon to move on :-)
Git may be ok, but I hear lots of horror stories from groups trying to get it to work well, which then invokes the fans to respond that they're doing it wrong, then it all goes down hill with twenty year olds scuffling with sixty year olds until the forty year olds break it up.
Re: (Score:2)
I don't think git and svn are even really comparable in that way. I used to be a proponent of svn, but since I learnt git properly, there is no going back to svn ever again. The entire philosophy is different at a fundamental level, completely changing the way at least I work with version control. Git is more like a flexible framework where I can juggle different versions and multiple development threads, reordering things, rebasing onto different branches, or even create completely new workflows (such as a
Re: (Score:2)
I've used sccs, rcs, cvs, svn, and git [all in production environments], spanning a 30 year period. git is easier to use than svn, and more powerful [features that git pioneered have been backported into svn, so you're getting the benefits, even if you don't realize it].
Ultimately, it's all about the merging, which is the premise that git is based on. See:
http://www.youtube.com/watch?v... [youtube.com]
or
http://www.youtube.com/watch?v... [youtube.com]
Re: (Score:2)
I might do it for some things, but right now the ability to only checkout a subdirectory[source [stackoverflow.com]] is paramount in the way we use svn around here.
You should go with what works for you, but just so you know, git has supported sparse checkouts for a few years now. Here is a blog post from 2011 [jasonkarns.com] that shows you how to do it, if you're interested. Admittedly, it has a not-obvious name, and is accomplished via not-obvious methods, but c'est la vie, sometimes.
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.
Again, you should use what works for you, but FYI, you're looking for gitlab [gitlab.com], or one of the other options out there (but I like gitlab, so that's what I'm going to link to).
All that being said, I don't
Re: (Score:2)
The biggest is that you have to think about what parts of the project you might want to check out individually before you start. For new (small) projects, it's sometimes easy, but typically project
About CVS Only! Not SVN! (Score:5, Insightful)
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.
If it works, leave it alone. (Score:5, Insightful)
Of course if you're starting a new repository then use the shinny new hammer with the rubber grip.
Re: (Score:2)
Move to svn (Score:2)
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.
Re:About CVS Only! Not SVN! (Score:4, Interesting)
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)).
Re: (Score:2)
(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 [github.io] will permanently delete
Re: (Score:2)
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 [google.com] is getting close, however, so I'm hopeful).
Re: (Score:2)
(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.
Re: (Score:3)
(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
Re: (Score:2)
Git can handle large repositories. (Score:2)
If by large you mean tens of megabytes. Downhill, with a stiff breeze at its back.
Re: (Score:2)
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 (an
Horrific Summary (Score:5, Informative)
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.
Re:Horrific Summary (Score:5, Insightful)
That would require the editors to be as literate as a five year old. That's just a cruel requirement.
Horrific Summary (Score:2, Insightful)
Do you expect anything else from timothy?
Counterpoint (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
There's submodules and subtrees, neither works all that well. SVN can pull down part of a repo, which is (IMO) slightly more sane behavior.
which is why I should learn mercurial (Score:2)
If Git did all that SVN does... (Score:5, Insightful)
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.
This is why they made the cloud (Score:2)
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
Re: (Score:3, Interesting)
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
Summary of what ESR is doing (Score:5, Informative)
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 [ibiblio.org]
Re: (Score:2)
Why do this instead of spinning up an Amazon AWS instance on demand? It shouldn't cost much to convert a source repository with that method, especially compared to buying a whole computer.
Re: (Score:2)
Seems like it'd be worthwhile to trial a real computer of similar spec to what he's wanting vs. a virtual server, to see relative speed and relative cost. You can get some pretty stonking powerful VPS instances if you're willing to pay for them, and with Amazon you can optimize for different workloads such as GPU, CPU, or fast IO.
There can't be that many projects on CVS who are sticking with it only because they're waiting for someone else to manage the switch to git, and you'd need a fair number to make t
Re: (Score:2)
For ECC, many modern Pentium and i3 CPUs also support ECC. See http://ark.intel.com/products/... [intel.com] for example - 2 core @ 3.8 GHz for $150, perfect for a single process task. Most i5 and i7s have ECC disabled. At that point, just pay the relatively small premium for the Xeon versions.
Amazon cloud (Score:2)
Fire up an amazon cloud instance configured for number crunching, do conversion, shut it down again. This shouldn't cost more than 50 bucks...
SVN will have its place for a long time (Score:3)
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.
Re: (Score:2)
this, this, a thousand times this.
I wish I'd seen your comment before I posted my own similar comment.
Where's my training wheels?? (Score:2)
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
reminds or sounds like? (Score:2)
> 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
NetBSD CVS repo already converted to git (Score:2)
Git Is Not The Be All End All (Score:4, Insightful)
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.
Re: (Score:2)
A single point of failure is a big problem. The biggest advantage of a distributed system is that the main repo doesn't have to take a variable client load that might interfere with developer pushes. You can distribute the main repo to secondary servers and have the developers commit/push to the main repo, but all readers (including web services) can simply access the secondary servers. This works spectacularly well for us.
The second biggest advantage is that backups are completely free. If something br
Re: (Score:2)
A single point of failure is a big problem.
Obviously, that's why you back it up and have fail-over if that's necessary. A single source of truth is a big plus, as is being able to use that single source of truth for code migrations to environments, history for audits, etc.
The second biggest advantage is that backups are completely free.
Nothing in this world is free. Using developer machines for backup isn't an optimal (or, IMO tenable) solution if you're serious about business continuity.
Re: (Score:2)
What unbelievable nonsense, but I suppose I shouldn't expect too much from an anonymous coward. You don't even realize that you proved my point with your response.
-Matt
It's not that big a deal (Score:2)
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 ge
A lot of to-do about $700 (Score:2)
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???
Re: (Score:2)
Over $900, and he will match the donations with his own funds so... that's definitely enough for a pretty nice machine. And with the slashdotting, probably a lot more now.
The bigger problem is likely network bandwidth to his home if he's actually trying to run the server at home. He'd need uplink and downlink bandwidth so if he doesn't have FIOS or Google Fiber, that will be a bottleneck.
-Matt
Unmaintained garbage (Score:2)
Compared to the code you'll find in a CVS or SVN these days, the VCS itself is the leadt of your problems.
Go back to the 90s (Score:2, Interesting)
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.
Re:I'm sorry what is collecting what? (Score:5, Funny)
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!!!!!
Re:I'm sorry what is collecting what? (Score:5, Funny)
Re: (Score:3)
Also, easier to buy Sudafed (or Meth) from drug dealers than to get Sudafed from a pharmacy.
Re: (Score:3)
I stay away from those dangerous drugs. There's nothing that a bottle of vodka and a Steven Seagal movie marathon can't cure.
Afrin (Score:3)
Re: (Score:3)
Oh come on, TFS [wikipedia.org] isn't bad enough to be flamebait!
Now, VSS [wikipedia.org], on the other hand...
Re: (Score:3, Informative)
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 Me
Re: (Score:2)
Visual SourceSafe would start corrupting repositories once they got above the 2 GB barrier. My last job had a 17 GB repository, and spent months trying to convert it to a different source control because of all the corruption issues.
17GB of source code? (Score:2)
17GB? Maybe you should not put binaries in your source code repository.
Re: (Score:2)
Why not? Binaries are still part of the application in many cases - images, videos, dependencies etc
Re: (Score:2)
Re: (Score:3)
Re:Mod TFS as flamebait (Score:5, Funny)
Yo dawg, I heard you like CVS so I put your pharmacy's dyslexic tabular data in version control.
...or something like that.
Re:esr will save us! (Score:4, Funny)
Re:esr will save us! (Score:5, Funny)
Clearly then, the next generation version control system should be named "Sexy Flanders".
Re: (Score:3)
My fucking monitor went tits up, and probably due to blown caps, you insensitive clod!
Re: (Score:2)
Who is ESR? Why is he/she/it supposed to be a household name around here?
Sigh, noobies.
Re: (Score:2)
... sounds like some rogue guy who wants to fork every project using CVS or SVN and stick them on Github or something.
Problem? Did you even bother to read the summary?
I'm just kidding, tee hee! :-) This's the sorta !@#$ we opensauce [sic] free software people do. Enjoy the ride. It's good for the soul.
Aaron, sleep in peace.
Re:Umm, what? (Score:5, Interesting)
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.
Re: (Score:2)
I swear, none of you people understand the meaning of the words "neoconservative/fringe libertarian nutbar after that business with the skyscrapers in '01."
It's just mind fwap & etc. Tea Partier == libertarian == GOP == conservative == WHAT?!?!?!?!?!?!
You're shallow as panes of glass! Think. Think harder! Concepts mean something. Don't listen to what MSM wants you to think of. THINK for yourselves!!!
I'm a libertarian, and your definition of what that word means is woefufully INADEQUATE, to say
Re: (Score:2)
Typical tea-partier, to get all riled up like that...
Re: (Score:2)
You're 0 for 2.
That's adorable that you're keeping score.
Re: (Score:2)
Don't be jealous, there's plenty of me to go around.
Re: (Score:2)
And comparing their work versus ESR on fetchmail is a classic case of glass house and thrown stones - but someone has to be a critic. Airing his political dirty linen and annoyance with investigative journalists in the "jargon file" was probably the point where he spent the capital of goodwill he had built up and was taken less seriously
Re: (Score:2)
This does sound like the perfect use-case for the cloud (of the 'rent a VM' type of cloud, such as AWS or Azure) - both for short term access to vastly more CPU, RAM or storage than you would reasonably want to be sharing a room with and also for the huge network bandwidth to the rest of the internet typically available from a cloud datacentre (AWS as an example capping out at 224GB RAM or 42TB or local storage).
However this is E.S.R. we are talking about so, aside from the possible issues with whether any
Re:Why git? (Score:5, Interesting)
.
Am I the only one concerned about the resulting monoculture if the GIT proponents have their way?
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
You can use git to commit onto an svn or perforce or whatever repository.
You get to use git locally, and the company gets to have its big central repository.
Re: (Score:2)
Bull. Shit.
Programming teams -- LARGE programming teams -- got along just fine without distributed version control for LITERALLY decades. I am on the fence about its usefulness in pure programming applications (like, as someone else mentioned, the kernel), but am absolutely opposed to its use for things like your configuration-management repository, the repo you store your DNS zonefiles in, etc., etc.
I would suggest to you th
Re: (Score:2)
You don't need DVCS for more than one developer, but certainly for some teams, organizations, and situations it offers a lot of benefits.
Fir a lot of projects the DVCS advantages are tenuous. A lot of regulated industries mandate by law fairly strict top-down control that erodes a lot of the DVCS benefits. A lot of projects are not pure software projects that have lots of required binaries files that git and mercurial are powerless to merge sensibly. A lot of organizations have a variety of projects all sto
Re: (Score:2)
> 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 ne
Re: (Score:2)
This isn't quite true. Git has no problem with large repos as long as the system ram and kernel caches can scale to the data footprint the basic git commands need to access them. However, git *DOES* have an issue with scaling to huge repos in general... it requires more I/O, certainly, and you can't easily operate on just a portion of a repo (a feature which I think Linus knows is needed). So repos which are well in excess of the RAM and OS resources required to do basic commands can present a problem.
Re: (Score:2)
Because he's looking to open it as a conversion server for pretty much anyone that wants to use it on an ongoing basis - which means that CapEx is a much better solution.