Help ESR Stamp Out CVS and SVN In Our Lifetime

Equivalent Series Resistance? by Obscene_CNN · 2014-10-20 09:11 · Score: 1, Redundant

Equivalent Series Resistance?

--
I don't want to do a sig now

Re:Equivalent Series Resistance? by Hognoxious · 2014-10-20 10:01 · Score: 2

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."

You had my curiosity... by gmhowell · 2014-10-20 09:15 · Score: 2

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

Re:You had my curiosity... by tqk · 2014-10-20 12:35 · Score: 3, 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.]

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.

Won't this alphabet soup ever end? by __aaclcg7560 · 2014-10-20 09:17 · Score: 1

Save-On -> Longs Drugs -> CVS -> ESR

3-letter challenge by istartedi · 2014-10-20 09:17 · Score: 5, Funny

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"?

Doesn't say SVN in TFA by Anonymous Coward · 2014-10-20 09:19 · Score: 5, Insightful

Nice trolling, dice.

Re:Doesn't say SVN in TFA by nickittynickname · 2014-10-20 10:09 · Score: 2

You're right, he doesn't say that in the article but he does say he's "on it " in the comments.

I am not going to convert by ModernGeek · 2014-10-20 09:21 · Score: 4, Insightful

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.

Re:I am not going to convert by gbjbaanb · 2014-10-20 09:47 · Score: 4, 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:I am not going to convert by Anonymous Coward · 2014-10-20 10:03 · Score: 1

At one employer, I used VSS for one year and then SVN for five years. At the next employer, I used SVN for four months and git (and git-svn) for the next year and a half. For software development, Git is superior in every way to SVN.
Talking about losing work; let's talk about "svn update". When I used SVN, my workflow for an update was:
* svn diff > ../stash.patch
* svn revert -R
* svn update #and hope to fuck that there wasn't some transient connection error, or other problem with the SVN server
* Examine changes to ensure that they were sane
* svn patch ../stash.patch
* rm ../stash.patch
If I didn't go through all of that rigmarole, ~80% of the time, something in the new code would clobber something in my WC. That's an unrecoverable situation.
Compare to git:
* git stash
* git pull $BRANCH
* git pop
Re:I am not going to convert by Anonymous Coward · 2014-10-20 10:19 · 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, 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 by Darinbob · 2014-10-20 10:47 · Score: 1

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:I am not going to convert by Alef · 2014-10-20 10:53 · Score: 1

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 process for formal code review before merging with the master branch). Every commit is small and adds one meaningful unit of functionality to the code base, and you can clearly see how features are composed of isolated strings of such commit, and how those features, possibly developed in parallel by different people, are merged into e.g. a common master branch in a coherent way.
Subversion, in comparison, is more like a kind of central, static trail log of everything that has been going on, where each commit is huge and usually intertwined with different other activities. Sure, theoretically you could work in the same way with svn, but that would be like saying I could use email in place of irc to do interactive text chatting; practicality simply prevents it from working that way.
I don't really understand why you see the need for a cloud solution to host a git repository, or why you even think it is easier to set one up with svn. Hosting a git repository is insanely trivial: you just put it on a machine with an ssh service running, and you're done! In fact, where I work, we regularly use each others' development computers as "hosts" when we pull and push topic branches between each other, before they are ready to go into the central repository. There is simply no setup other than creating a user account.
Re:I am not going to convert by Darinbob · 2014-10-20 10:57 · 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:I am not going to convert by AJodock · 2014-10-20 11:17 · Score: 1

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
That is because all that you need for GIT is a local directory, SSH, or a Web server. Since your client has a full copy of the repository you can always just fire up gitweb on a local repository.
If you need a GUI to satisfy your needs there is the official web GUI that is distributed with git again no hosting required.
https://git.wiki.kernel.org/in...
If you want more advanced features like Git Hub:
https://about.gitlab.com/ (a near clone of Git Hub)
https://gitorious.org/
and dozens of others (https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools)
I will +1 on the sub-directories deal, but for my use case I just made the sub-directories GIT submodules and everything works itself out. If your sub-directories are really separate parts of a larger project you probably should already have them in separate repositories anyways.
Re:I am not going to convert by Forever+Wondering · 2014-10-20 11:24 · Score: 1

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...
or
http://www.youtube.com/watch?v...

--
Like a good neighbor, fsck is there ...
Re:I am not going to convert by Alef · 2014-10-20 11:34 · Score: 1

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 either need to keep all your work in one huge uncommitted blob in the working copy, or you need to commit half-finished work into the central repository. With Git, you can keep your topic branch floating nicely on top of the master branch's head, while building it step by step in multiple commits. There is simply no sane way to do that with SVN.
Re:I am not going to convert by phantomfive · 2014-10-20 13:23 · Score: 1

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).

--
"First they came for the slanderers and i said nothing."
Re:I am not going to convert by Slashdot+Parent · 2014-10-20 13:51 · Score: 1

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 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, 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 think there's any reason for you to convert to git if svn is getting the job done for you. One day in the future you'll work on a project that's hosted in git and you'll learn it then.

--
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Re:I am not going to convert by phantomfive · 2014-10-20 13:57 · Score: 1

The developers in your example used "git reflog" (a standard git command used to undo things) to undo the problem. In other words, yes, it can be undone. You should at least read your links before posting them.......

--
"First they came for the slanderers and i said nothing."
Re:I am not going to convert by Slashdot+Parent · 2014-10-20 14:00 · Score: 1
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:
1. 1. You have no backups ("backups" includes pushing your commits to a remote server, and
2. 2. You go mucking about in your .git directory and start randomly changing files in there or deleting them without knowing what you're doing
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 commands to interact with your .git directory.
When you claimed that you could lose history irrevocably, you were probably referring to hard resets and whatnot. Just so you know, the git reflog will still contain your commits, and you can get them back even after a hard reset. I'm not going to lie and say that this is a simple process, but it's there if you need it.
--
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Re:I am not going to convert by s.petry · 2014-10-20 16:02 · Score: 1

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 need heavy collaboration. Our products code base is in SVN because there is large collaboration. We have about 7 times the amount of developers you have, and the various teams have all tested git and decided to stick with SVN.
When management allows free for all, I recommend Clearcase/Rational so that you have full control over who has access to what files in a branch, not just a branch. It's expensive, but no more chaos.

--
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Re:I am not going to convert by WuphonsReach · 2014-10-20 16:44 · Score: 1

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.

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, and they're constantly working to improve it. Git, Mercurial or other DVCS systems are just better at that.

(shrugs) I've looked at git, mercurial and subversion - and SVN is just easier for regular users to understand. The main hurdle they have is learning the update / modify / commit cycle and that the shorter the cycle, the better things work. Plus, learning not to leave their working copy / development areas dirty with uncommitted changes.

--
Wolde you bothe eate your cake, and have your cake?
Re:I am not going to convert by Alef · 2014-10-20 19:56 · Score: 1

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 "trace" of what you have been doing (I notice how you even refer to it as a "log"), rather than a graph describing how different snapshots of the code base relate to each other logically. It has nothing to do with it being "pretty" and everything to do with maintainability. If you need to lift a feature developed in for example one fork of a project into another, it is much better if the development of that feature is clearly separated and logically related to other version of that fork's code base, than as something that "happened" somewhere in a chronological history at some point. This is a fundamental philosophical difference between how most people work with SVN versus how most people work with Git, and one of the strongest aspects of Git IMO.
Re:I am not going to convert by TheRaven64 · 2014-10-20 23:33 · Score: 1

You can checkout a subdirectory if (and that's a big proviso) you structure your code in such a way that each directory is a separate git repository, referenced as a submodule. The submodule points to a specific version of the other repository. Unfortunately, there are still a lot of issues with this approach:
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 projects grow organically and parts get factored out. There's no good way of turning a subtree in a git repo into a new repo preserving history (and no way at all that allows you to merge into both).
The second big one is that you lose atomic commits (the thing we all switched to svn from cvs for in the first place). If you only have one layer of submodules, it's quite nice because committing something to the submodule and updating the version of the submodule are independent. That means that you can make changes to a component, unit test them, commit, and then later update their consumers. Unfortunately, there's no way of atomically updating two independent subtrees simultaneously.
The third annoyance is the most embarrassing for a DVCS: the remote repository for upstream is identified by an absolute URL. You can do relative URLs, but they don't work very well, which means that if you want people to use a local version then it's quite convoluted. There's no simple 'clone this repo and all of the submodules in such a way that someone else can clone my copy and it all work sensibly'.
In general, the dire UI of git has been an unexpected advantage. No one can stand working with it, so people have been motivated to write nice GUIs that make it tolerable.

--
I am TheRaven on Soylent News
Re:I am not going to convert by gbjbaanb · 2014-10-20 23:38 · Score: 1

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 you cannot ever obliterate history is a good one, one that all other SCMs should follow. If you commit something you shouldn't, it should be a serious thing to remove that history - otherwise everyone will screw your SCM up, and your SCM is the one thing you do not ever want screwed up.
Re:I am not going to convert by gbjbaanb · 2014-10-20 23:41 · Score: 1

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:I am not going to convert by gbjbaanb · 2014-10-20 23:47 · Score: 1

You have the same log history in git as you do in Svn - a linear chain of commits. What you describe as a tree is due to the branching and merging. SVN has the same thing, you branch just as much as you do with git, the difference is how the 2 store this information internally.
eg where I work, we use feature branches for independant development. Then the final fixes get merged to the product release branches and trunk. Not too dissimilar from how you tend to use git.
I worked at a place that used git (alas, not me, I was in the Windows team and had to use TFS :( ) and too many people used ot have to call the git guru over because they would munge up their repos. I don't know how they did it, but the fact that they did it too often for my tastes suggests git is a tool that is only for advanced, or experienced users only. Unfortunately that means nowhere near enterprise development.
Today, I'd never suggest git, I'd go with Fossil if I needed a DVCS.
Re:I am not going to convert by tqk · 2014-10-21 01:23 · Score: 1

Read up on IBM's lucrative sales to Nazi Germany back in the day. (Yeah! I went there! Woohoo goodwin!)
+1 on the IBM history, -1 on http://en.wikipedia.org/wiki/G...
Keep tryin'. Ya learn something new every day, hopefully.

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
Re:I am not going to convert by tqk · 2014-10-21 02:05 · Score: 1

If something is working, there's no point in trying to break it.
If something is working, that's the incentive to try to break it. If it survives the attempt, it deserves the respect. If it doesn't (breaks), it gets better (fixed), or replaced. Progress.
I'd like to define this as the Dirty Harry Principle. "Did I fire six shots, or only five?" "Hey man, I gots to know!"
He wants to know *so much* that he's willing to die in order to find out.

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
Re:I am not going to convert by s.petry · 2014-10-21 04:42 · Score: 1

My point was really along the lines of "What happens when 50 developers all pull the full tree and try to commit it all back?" Usually lock contention, and people hammering all of their files into place. I agree that the problem is not SVN, but this is harder to fix without some draconian measures like Rational.

--
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Re:I am not going to convert by Alef · 2014-10-21 08:56 · Score: 1

Admittedly, my experience with TFS is a bit limited, but what you are describing is not the same thing. In fact, it highlights one of the problems I was talking about: With SVN, because dealing with branches is more cumbersome, people use the working copy as the place where they do their work. The result is that you have no version management of the work you are doing until you commit to the central repository.
This is not how you work with Git. With Git, you commit often. Every commit is tiny; it's the smallest possible atom of work which can't be divided further in any meaningful way. Before I started using Git, there was a whole lot of commenting out lines back and forth, committing only a selection of the dirty files in my working copy, and all kinds of similar things which effectively amounts to a kind of error prone, small-scale revision management by hand. Now all this is handled by Git, and it does it much better. Every change can be traced, reordered, combined, split, and so on. So when I say that my topic branch is floating nicely on top of the master, I'm not talking about the stuff in my working copy, I'm talking about my local revision history.
Furthermore, what I'm saying is not that certain things are impossible to do with Subversion. I'm saying that the mechanics of those things are so different that it fundamentally changes how you think of an use revision control in practice. It took me a few months of intensive Git usage to realise that.
Re:I am not going to convert by jez9999 · 2014-10-21 22:53 · Score: 1

What are you talking about?
You can easily have a centralized git repo that does regular backups. That's what Bitbucket, Github, etc. do.

--
== Jez ==
Do you miss Firefox? Try Pale Moon.
Re: I am not going to convert by cheekyboy · 2014-10-22 01:42 · Score: 1

The fact that lots people have issues with git is proof its not designed well. Even Linus said git is not designed to be easy and nice but hard like 1982 Solaris or vms.

--
Liberty freedom are no1, not dicks in suits.
Re:I am not going to convert by Dr_Barnowl · 2014-10-22 09:34 · Score: 1

Indeed.
VSS had this feature. It was called "Purge".
If you used it, it destroyed the entire history of the given source file. It was then no longer possible to replicate any build that included that file, ever again. That's a bad thing, in a revision control system.
Re:I am not going to convert by Ben+Hutchings · 2014-10-26 04:49 · Score: 1

the trouble with DVCSs is there is no repository to backup.
There are many repositories you can backup. It's a matter of policy for each project to choose which of these is the authoritative version.

Everyone has their copies and a vape in one can (and will) be propagated to the others.
It sounds like you are talking about non-fast-forward pushes. These can be disallowed, and I think that's the default but I could be wrong. It's also not necessary to allow all developers to push to the authoritative repository (which you can't do with a centralised VCS).

Its not like a centralized system where you can have proper backups.
No, it's much better.
Re:I am not going to convert by chipschap · 2014-11-01 06:01 · Score: 1

Heh. I still use RCS :) Definitely good enough for one person projects. I use it (in conjunction with EMACS) for fiction writing.
My point? Fit the tool to the job. RCS is old and doesn't scale well, but what I'm doing only requires something simple and straightforward. CVS, SVN, GIT --- all are overkill for me.

Re:I'm sorry what is collecting what? by NotDrWho · 2014-10-20 09:21 · Score: 4, 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!!!!!

--
SJW's don't eliminate discrimination. They just expropriate it for themselves.

Re:Mod TFS as flamebait by mrchaotica · 2014-10-20 09:22 · Score: 2

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

Re:Mod TFS as flamebait by ArhcAngel · 2014-10-20 09:22 · Score: 1

Shouldn't that last line be 1st hater? And who else saw CVS and wondered why Eric would want to stamp out comma delimited files (CSV...I know dyslexia)?

--
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K

Help stamp out Git in my lifetime by Anonymous Coward · 2014-10-20 09:23 · Score: 1

And whatever shall we do with the bathwater now that the baby is gone?

About CVS Only! Not SVN! by Anonymous Coward · 2014-10-20 09:23 · 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.

Re: About CVS Only! Not SVN! by Anonymous Coward · 2014-10-20 09:54 · Score: 1

He's also written Reposurgeon, an excellent program for converting repositories, including SVN to your favorite DVCS.

A bit silly by softwaredoug · 2014-10-20 09:26 · Score: 1

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

Re:A bit silly by anarcobra · 2014-10-20 14:09 · Score: 1

It doesn't really matter though.
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:A bit silly by CSMoran · 2014-10-21 00:32 · Score: 1

Seconded. I use git locally and then commit to a central svn repository via git-svn. The git-svn interface is a bit fragile, but the ease of merging nontrivial changes git-side rather than svn-side makes up for that.

--
Every end has half a stick.

Re:Umm, what? by Nimey · 2014-10-20 09:28 · Score: 1, Troll

And then he turned into a neoconservative/fringe libertarian nutbar after that business with the skyscrapers in '01.

--
Hail Eris, full of mischief...

E pluribus sanguinem

Re:Mod TFS as flamebait by reboot246 · 2014-10-20 09:28 · Score: 2

I'm more concerned about CVS. Where am I going to get my prescriptions filled?!?

Re:Mod TFS as flamebait by mrchaotica · 2014-10-20 09:28 · Score: 4, Funny

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

Re:esr will save us! by DMUTPeregrine · 2014-10-20 09:31 · Score: 3, Funny

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!

Horrific Summary by Anonymous Coward · 2014-10-20 09:34 · 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 by Lunix+Nutcase · 2014-10-20 09:48 · Score: 4, Insightful

That would require the editors to be as literate as a five year old. That's just a cruel requirement.

CapEx vs OpEx by vanye · 2014-10-20 09:35 · Score: 1

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 ?

Re:CapEx vs OpEx by vanye · 2014-10-20 12:35 · Score: 1

s/his bedroom/parent's basement/
s/lesser mortal/democrat/
Re:CapEx vs OpEx by Richard_at_work · 2014-10-20 22:01 · Score: 1

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.
Re:CapEx vs OpEx by Rich0 · 2014-10-21 05:08 · Score: 1

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.
Let's assume that a conversion takes 5 hours on EC2 at 25 cents/hour. Do we really think that there are 2000 repositories out there that need to be converted?
And if there are, then wouldn't it be nice to be able to convert them 10 at a time instead of doing them sequentially?
This is really a model case for a cloud solution.

Re:I'm sorry what is collecting what? by ArhcAngel · 2014-10-20 09:36 · Score: 5, Funny

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

Counterpoint by Tenebrousedge · 2014-10-20 09:36 · Score: 4, 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.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.

Re:Counterpoint by Alef · 2014-10-20 11:11 · Score: 1

I agree there are some things that could be improved with Git's submodule feature (I assume you are aware of it, though you called it something else), but is SVN's externals really that much better? In my experience, both works, each with it's own pros and cons, though neither of them is "extremely painful".
Re:Counterpoint by Tenebrousedge · 2014-10-20 11:55 · Score: 1

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.

--
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.

Horrific Summary by Anonymous Coward · 2014-10-20 09:50 · Score: 2, Insightful

Do you expect anything else from timothy?

Re:Mod TFS as flamebait by WuphonsReach · 2014-10-20 09:56 · Score: 2, Informative

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?

Re:Umm, what? by Alomex · 2014-10-20 10:04 · Score: 4, 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:I'm sorry what is collecting what? by Austerity+Empowers · 2014-10-20 10:05 · Score: 2

Also, easier to buy Sudafed (or Meth) from drug dealers than to get Sudafed from a pharmacy.

Re:esr will save us! by sconeu · 2014-10-20 10:10 · Score: 4, Funny

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.

Re:old schoolers who haven't heard... by Confuse+Ed · 2014-10-20 10:10 · Score: 1

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 of the cloud providers are compatible with his larger philsophical aims, who knows what other interesting ideas he might come up with given access to much more powerful personal computer hardware rather than having his creativity shackled by the limitations of his current systems.

Re:About CVS Only! Not SVN! by Anonymous Coward · 2014-10-20 10:17 · Score: 1

CVS should die though, yes.

Yes CVS should die. this is why I stuck with RCS.

If it works, leave it alone. by TapeCutter · 2014-10-20 10:19 · Score: 5, Insightful

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.

Re:If it works, leave it alone. by Just+Some+Guy · 2014-10-20 10:48 · Score: 1

The problem is that you're building more and more tooling on top of a painfully decrepit system. Every time you spend more than zero seconds dealing with renaming a file, you've lost money on the deal. Every time you work off HEAD because it's too painful to branch, you're spending developer salaries. I get that "if it ain't broke, don't fix it", but CVS it utterly and fundamentally broke. You're throwing good money after bad trying to keep it alive.

--
Dewey, what part of this looks like authorities should be involved?

If Git did all that SVN does... by jdege · 2014-10-20 10:34 · 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.

--
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

Re:I love how stupid these morons are... by Anonymous Coward · 2014-10-20 10:34 · Score: 1

> 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.

This is why they made the cloud by Just+Some+Guy · 2014-10-20 10:36 · Score: 1

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?

Re:This is why they made the cloud by Anonymous Coward · 2014-10-20 12:15 · 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 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.
Re:This is why they made the cloud by Rich0 · 2014-10-21 05:19 · Score: 1

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.
It would make sense to at least test the whole concept in the cloud before buying hardware. That costs almost nothing to do, and then it can point you to just what you need in a server.
It seems like most of the proposals on that website are MORE MORE MORE of everything. What about RAM? 64GB, ECC! What about disk? 4 250GB SSDs in RAID10! What about multi-thread? Gotta have 16 cores! What about single-thread? Better make that dual Xeons so that we can use the ECC RAM and since those are the best! Does it need fancy graphics? Nope, so we better build a second system to use as a console for the big one so that it can be put in another room so that you don't hear the hurricane of fans! Wait, noise? Ok, scratch that, let's buy some big fancy cooling rigs even though we aren't overclocking so that it is as quiet as a mouse, but let's still build that second console!
Why not at least profile the thing in the cloud and figure out what you really need?

Summary of what ESR is doing by steveha · 2014-10-20 10:39 · 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

--
lf(1): it's like ls(1) but sorts filenames by extension, tersely

Re:Summary of what ESR is doing by Nimey · 2014-10-20 12:46 · Score: 1

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.

--
Hail Eris, full of mischief...

E pluribus sanguinem
Re:Summary of what ESR is doing by Nimey · 2014-10-20 13:48 · Score: 1

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 this worthwhile, IMO. I think he may be tilting at windmills.

--
Hail Eris, full of mischief...

E pluribus sanguinem
Re:Summary of what ESR is doing by leiz · 2014-10-20 20:47 · Score: 1

For ECC, many modern Pentium and i3 CPUs also support ECC. See http://ark.intel.com/products/... 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.

SVN will have its place for a long time by JPyObjC+Dude · 2014-10-20 10:47 · Score: 2

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:SVN will have its place for a long time by Dredd13 · 2014-10-20 14:22 · Score: 1

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.
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?? by tjb6 · 2014-10-20 10:55 · 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 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!

Re:Why git? by QuietLagoon · 2014-10-20 11:17 · Score: 4, Interesting

So far, all I've seen are GIT proponents saying everyone should use GIT. What if CVS or SVN does all you need? Why switch?

.
Am I the only one concerned about the resulting monoculture if the GIT proponents have their way?

reminds or sounds like? by 2fuf · 2014-10-20 11:32 · Score: 1

> 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

Re:Mod TFS as flamebait by Eunuchswear · 2014-10-20 11:32 · Score: 1

Shouldn't that last line be 1st hater? And who else saw CVS and wondered why Eric would want to stamp out comma delimited files

Fuck, who wouldn't want to stamp out comma delimited files.

The fuckers usualy aren't even delimited with a comma!

--
Watch this Heartland Institute video

NetBSD CVS repo already converted to git by Dahan · 2014-10-20 11:33 · Score: 1

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.

Re:Umm, what? by Anonymous Coward · 2014-10-20 11:35 · Score: 1

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.

Except that even that is questionable. Linux has never split into multiple projects which displayed fruitful inter-breeding and competition in the "marketplace of ideas", so the concept of the Bazaar does not seem a great analogy to the way the development process actually works. There has always been basically one mainline thrust of development steered ultimately by Linus T. Any side projects (more significant than drivers for a particular piece of hardware) either get incorporated into the main line within about 9 months, maybe 18 months maximum, or they die out. The only significant long-term fork of Linux I can think of is Android. There is also some interaction with the BSD family, but not that much. Overall, the development process looks more like the Cathedral to me when you look at timescales greater than a few months.

Re:git? by Eunuchswear · 2014-10-20 11:35 · Score: 1

I resemble that remark.

(It's a lot harder to change a SCCS based workflow into git than you would think).

--
Watch this Heartland Institute video

Fossil is awesome (was: I am not going to convert) by datadigger · 2014-10-20 11:40 · Score: 1

> git done right.

I agree 100%
www.fossil-scm.org

--
Aphorisms don't fix code. (Bart Smaalders)

Re:old schoolers who haven't heard... by Eunuchswear · 2014-10-20 11:44 · Score: 1

However this is E.S.R. we are talking about so, aside from the possible issues with whether any of the cloud providers are compatible with his larger philsophical aims

ESR (Looks like Fortran to him) has "larger philosophical aims"?

who knows what other interesting ideas he might come up with given access to much more powerful personal computer hardware rather than having his creativity shackled by the limitations of his current systems.

Oh, I've been trolled, how silly of me.

--
Watch this Heartland Institute video

See no need to go to git by Anonymous Coward · 2014-10-20 11:44 · Score: 1

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.

Re:About CVS Only! Not SVN! by cdecoro · 2014-10-20 11:54 · Score: 3, 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)).

Afrin by tepples · 2014-10-20 12:16 · Score: 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.

Repository or suppository? by tepples · 2014-10-20 12:18 · Score: 1

What kind of butt drugs are you on?

Re:Mod TFS as flamebait by Linknoid · 2014-10-20 12:30 · Score: 1

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.

which is why I should learn mercurial by csirac · 2014-10-20 12:49 · Score: 1

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

Re:Umm, what? by Cramer · 2014-10-20 12:51 · Score: 1

There's the kernel.org "master" linux, then the various side-branches for various developers, subsystems, and the like that does find its way back into the "linus tree" in part or whole. Then there's the significant stack of modifications found in almost all major distributions. And then there are a number of very specialized "forks" that most have never heard of, or care about. (Android is the only one most have heard of, but many don't know it's Linux.)

Re:Umm, what? by cold+fjord · 2014-10-20 12:56 · Score: 1

And then he turned into a neoconservative/fringe libertarian nutbar after that business with the skyscrapers in '01.

Do you have any proof of that? In this Slashdot interview from 1999, which you will astutely note is before 9/11, people were complaining about him in similar terms to today. What is this big change that you claim happened? Is there something in his writings or blog?

After 9/11 some people went cold turkey on the bat shit insanity that they had been involved in, others found a moment or two of sanity and then relapsed. And some others couldn't even manage that.

You seem to have made clear how you view ESR, but I guess we know where you stand too, eh?

--
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell

Re:Umm, what? by phantomfive · 2014-10-20 13:19 · Score: 1

Who is ESR? Why is he/she/it supposed to be a household name around here?

Sigh, noobies.

--
"First they came for the slanderers and i said nothing."

Re:I am beggining to think ESR needs to stop talki by styrotech · 2014-10-20 13:45 · Score: 1

2. He seems to do more talking about software than he does actually writing it.

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:Umm, what? by cold+fjord · 2014-10-20 13:47 · Score: 1

Actually I'm not a Libertarian (big or small "L"), but they often have ideas worth some consideration. You're 0 for 2.

I am curious now though. You're an "apostate" libertarian? That would make you formerly a libertarian. Where did you go wrong?

--
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell

Re:Umm, what? by Nimey · 2014-10-20 13:50 · Score: 1

You're 0 for 2.

That's adorable that you're keeping score.

--
Hail Eris, full of mischief...

E pluribus sanguinem

17GB of source code? by lucm · 2014-10-20 14:05 · Score: 1

17GB? Maybe you should not put binaries in your source code repository.

--
lucm, indeed.

Re:17GB of source code? by fennec · 2014-10-20 18:45 · Score: 1

A repository is not just a bunch of source files, you also store all the history of file changes and commit log.
Re:17GB of source code? by Richard_at_work · 2014-10-20 21:54 · Score: 1

Why not? Binaries are still part of the application in many cases - images, videos, dependencies etc
Re:17GB of source code? by lucm · 2014-10-21 08:27 · Score: 1

17GB of source code or history? In a single company? Nope.
The guys talks about SourceSafe, and I'd bet this 17GB repository is filled with tons of duplicated binaries. That's typical in Microsoft shops where people don't configure Visual Studio properly; each reference creates a copy of the relevant DLLs in the project's bin folder, and references to other projects bring a copy of that project's latest build but also all its DLL.
I have a client with that kind of setup. They have a bunch of related projects under source control; for a total of 200 files of source code, the size of the repository is over 700MB.

--
lucm, indeed.
Re:17GB of source code? by lucm · 2014-10-21 08:33 · Score: 1

Why would you put things that you can't merge or diff in a source code repository? It's not a backup system or a file server. For images and videos, you should use a digital asset management system. For dependencies you should use a CMDB.

--
lucm, indeed.
Re:17GB of source code? by Richard_at_work · 2014-10-21 19:05 · Score: 1

Why the duck would I need to do anything like that when including them in my git repo works fine? It also means I can deploy directly from git into my environments.

Re:I'm sorry what is collecting what? by lucm · 2014-10-20 14:10 · Score: 2

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.

Re:About CVS Only! Not SVN! by Slashdot+Parent · 2014-10-20 14:13 · Score: 1

(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

Git Is Not The Be All End All by Dredd13 · 2014-10-20 14:21 · Score: 3, 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:Git Is Not The Be All End All by m.dillon · 2014-10-20 15:14 · Score: 1

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 breaks badly, a repo will be out there somewhere (and for readers one can simply fail-over to another secondary server or use a local copy).
For most open source projects... probably all open source projects frankly, and probably 90% of the in-house commercial projects, a distributed system will be far superior.
I think people underestimate just how much repo searching costs when one has a single distribution point. I remember the days when FreeBSD, NetBSD, and other CVS repos would be constantly overloaded due to the lack of a distributed solution. And the mirrors generally did not work well at all because cron jobs doing updates would invariably catch a mirror in the middle of an update and completely break the local copy. So users AND developers naturally gravitated to the original and subsequently overloaded it. SVN doesn't really solve that problem if you want to run actual repo commands, verses greping one particular version of the source.
That just isn't an issue with git. There are still lots of projects not using git, and I had a HUGE mess of cron jobs that had to try very hard to keep their cvs or other trees in sync without blowing up and requiring maintainance every few weeks. Fortunately most of those projects now run git mirrors, so we can supply local copies of the git repo and broken-out sources for many projects on our developer box that developers can grep through on our own I/O dime instead of on other project's I/O dime.
-Matt
Re:Git Is Not The Be All End All by m.dillon · 2014-10-20 19:28 · Score: 1

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
Re:Git Is Not The Be All End All by dwpro · 2014-10-20 23:16 · Score: 1

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.

--
Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. -- Susan Ertz
Re:Git Is Not The Be All End All by oojah · 2014-10-21 02:23 · Score: 1

On the "single source of truth" point, I don't think this is incompatible with distributed version control. Just make it your policy that a given repository is the canonical source.

If their existing SCM application is working for them, and they're happy with it, then it's perfectly fine.

Agreed.

--
Do you have any better hostages?
Re:Git Is Not The Be All End All by markkezner · 2014-10-21 03:48 · Score: 1

Git is perfectly capable of having a repo that is considered the "single source of truth". All you have to do is tell everyone which repository to consider the "main" one.
The reason it's fine to use any random developer's git repository to restore is because the data's integrity is guaranteed by git's design. Let's say you had some disaster and lost your repository. Suppose you found a random developer (that you don't necessarily trust) who has a git repository that is a clone of your old, destroyed repository. You can safely and confidently restore from his copy so long as they have a commit id (hash) that matches exactly with a known hash from the original repository. If the hashes match then his copy at that commit is guaranteed to exactly match, bit for bit, your original repository. Compromising that integrity would be extraordinarily hard.
Of course you shouldn't rely on random developers having copies, just out of pure luck. Make your own backups and keep them safe.

--
Dangerous, sexy, turing complete: Femme Bots

Re:See no need to go to git by Dredd13 · 2014-10-20 14:25 · Score: 1

If you have more than 1 programmer you have a need for distributed version control.

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 that if you think the only thing people are using version control for is "source code", then you don't understand the enterprise.

Re:Umm, what? by Nimey · 2014-10-20 14:30 · Score: 1

Don't be jealous, there's plenty of me to go around.

--
Hail Eris, full of mischief...

E pluribus sanguinem

Re:See no need to go to git by Whatsisname · 2014-10-20 14:35 · Score: 1

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 stored in a single repository for whatever reason, and having to clone the entire thing for a single project is a nuisance.

For situations like those, which are commonplace in the commercial world, SVN and the centralized model is a fine way of doing things.

In my experience, DVCS is excellent for pure software projects, and sucks for anything else. SVN on the other hand is a great tool that is useful for a great number of projects beyond software.

In otherwords, use the tool with the right capabilities for the task at hand, not because of what's trendy.

It's not that big a deal by m.dillon · 2014-10-20 14:41 · Score: 1

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

Re:Not a religious war, but it sounds retarded ... by Antique+Geekmeister · 2014-10-20 14:54 · Score: 1

> 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.

Re:SVN and Git are not good for the same things by m.dillon · 2014-10-20 15:02 · Score: 1

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. Google has precisely this problem and it is why they are unable to use git despite the number of employees who would like to.

Any system built for home or server use by a programmer/developer in the last 1-2 years is going to have at least 16G of ram. That can handle pretty big repos without missing a beat. I don't think there's much use complaining if you have a very old system with a tiny amount of ram, but you can ease your problems by using a SSD as a cache. And if you are talking about a large company... having the repo servers deal with very large git repos generally just requires ram (but client-side is still a problem).

And, certainly, I do not know a single open source project that has this problem that couldn't be solved with a measily 16G of ram.

-Matt

A lot of to-do about $700 by putaro · 2014-10-20 15:04 · Score: 1

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:A lot of to-do about $700 by m.dillon · 2014-10-20 15:20 · Score: 1

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

Re:About CVS Only! Not SVN! by DutchUncle · 2014-10-20 15:52 · Score: 1

(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.

Git can handle large repositories. by Brannon · 2014-10-20 16:05 · Score: 1

If by large you mean tens of megabytes. Downhill, with a stiff breeze at its back.

Re:Git can handle large repositories. by CSMoran · 2014-10-21 00:19 · Score: 1

I would like to offer a radically different experience. I use a git repository for synching *all* my work-related files (binary or not) across four machines, one of them located abroad. Two of those repository copies are on a VirtualBox filesystem, accessed from a virtualized PC, and for one of these the .vdi file resides on a SATA HDD drive mounted over USB2, so rather low-end performance. The repository is currently at 74 GB (yes, GB), and I am entirely satisfied with git's performance when it comes to adding, merging, checking out, and so on. Only the initial git add/commit/push cycle that sent the first 50 GB abroad was a bit cumbersome (took overnight). Admittedly, this is only a huge master branch and a temporary 'scratch' branch that I switch to when pushing files between the repos, but still, I expect to hit 100 GB in a year or two and no complaints.

--
Every end has half a stick.

Re:Umm, what? by dbIII · 2014-10-20 16:17 · Score: 1

He also tore CUPS authors and the open source user interface authors a new one in an infamous essay

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

Unmaintained garbage by Ukab+the+Great · 2014-10-20 16:24 · Score: 1

Compared to the code you'll find in a CVS or SVN these days, the VCS itself is the leadt of your problems.

Re:Umm, what? by tqk · 2014-10-20 16:51 · Score: 1

... 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.

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.

Re:Why git? by complete+loony · 2014-10-20 17:04 · Score: 1

Every time I'm forced to use SVN or TFS, I'm annoyed by how difficult it is to work on multiple patches for multiple features at the same time. With git I can create my own local feature branches, and create as many versions of each patch series as I want, until I'm happy to push them for review. And I never feel like I'm at risk of losing any half finished work I've already completed.

--
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.

Re:Umm, what? by tqk · 2014-10-20 17:17 · Score: 1

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 the least.

Do some fscking basic research, then speak.

I'm not a Tea Partier, and you can't imagine how insulting that is to me!

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.

Re:Umm, what? by 91degrees · 2014-10-20 19:08 · Score: 1

He already was a neo-conservative fringe Libertarian. It just became more apparent after he ran out of geek things to talk about.

Go back to the 90s by HnT · 2014-10-20 21:10 · Score: 1, 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.

--
"Only one thing is impossible for God: To find any sense in any copyright law on the planet." - Mark Twain

Re:Go back to the 90s by Anonymous Coward · 2014-10-21 04:54 · Score: 1

I for one am going to create a whole bunch of SVN repositories now, just because.
Whether an idea is intrinsically good is independent of the character of the person promoting it. If he were Hannibal Lecter, it would still be a good idea to move some projects from cvs to git.

Amazon cloud by HnT · 2014-10-20 21:13 · Score: 1

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

Move to svn by HnT · 2014-10-20 21:17 · Score: 1

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

Re:Umm, what? by GNious · 2014-10-20 22:12 · Score: 1

Typical tea-partier, to get all riled up like that...

Re:About CVS Only! Not SVN! by cdecoro · 2014-10-20 22:47 · 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.

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.

Re:About CVS Only! Not SVN! by cdecoro · 2014-10-20 22:52 · Score: 1

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).

Re:About CVS Only! Not SVN! by orzetto · 2014-10-20 23:11 · Score: 1

[...] because those files are binary and very large

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.

(2) permanently delete those files that I know I will no longer need

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

Re:About CVS Only! Not SVN! by TheRaven64 · 2014-10-20 23:40 · Score: 1

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

Re:Umm, what? by MaskedSlacker · 2014-10-20 23:43 · Score: 1

That's true. You're not a libertarian. They don't get as turned on by men-in-jack-boots as you do.

Re:About CVS Only! Not SVN! by soccerisgod · 2014-10-21 00:33 · Score: 1

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?

Re:Umm, what? by tqk · 2014-10-21 00:44 · Score: 1

He is actually quite a dick to people ...

Gee, where've I heard that before? Perhaps every time I've heard of geeks being talked about?

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.

Re:git? by tqk · 2014-10-21 00:50 · Score: 1

I use mercurial, you insensitive clod!

I use SCCS and I LIKE it you insensitive clod!

My source code control system is my text editor! Make is all anyone should need!

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.

Re:Umm, what? by cold+fjord · 2014-10-21 01:06 · Score: 1

You do realize that libertarians aren't the people that run libraries, right?

--
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell

Re:Umm, what? by Nimey · 2014-10-21 01:13 · Score: 1

You say that as though it's impossible to hold ideas from different groups simultaneously. How charmingly naive.

--
Hail Eris, full of mischief...

E pluribus sanguinem

Re:About CVS Only! Not SVN! by Slashdot+Parent · 2014-10-21 01:15 · Score: 1

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

Instead of money, how about hardware? by grilled-cheese · 2014-10-21 04:34 · Score: 1

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.

Re:Not a religious war, but it sounds retarded ... by angel'o'sphere · 2014-10-21 08:12 · Score: 1

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.

Re:Umm, what? by columbus · 2014-10-21 09:03 · Score: 1

I disagree about the 'single shining moment'. For myself, I'm a fan of 'The Art of UNIX Programming'.

--
friends don't let friends teleport drunk

Re:Not a religious war, but it sounds retarded ... by Antique+Geekmeister · 2014-10-21 09:35 · Score: 1

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.

Re:Why git? by complete+loony · 2014-10-21 10:47 · Score: 1

That's not what I'm talking about, and I can and have done that with git using only a single copy of the history of the repository.

I mean that I can make a whole bunch of changes to one file, then tease those changes apart into multiple patches and commit them in the order I want. And if I'm not happy with how things ended up, I can re-order or re-write those patches before I push them upstream. To do the same in a single branch with SVN, I'd have to copy the file, revert it, then manually apply each change one at a time. Hoping that I get everything right the first time.

If I want to run a suite of tests against every patch one at a time, I can script that in a couple of minutes. Or if I notice that something is broken, I can do a binary(-ish) search of everything I've done to find it.

Mastery of git makes almost any workflow possible.

--
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.

Re:I'm sorry what is collecting what? by loimprevisto · 2014-10-22 03:38 · Score: 1

You don't need to go to a drug dealer for that, you can do it right from the comfort of your home!
"A novel and straightforward synthesis of pseudoephedrine from readily available N-methylamphetamine is presented. This practical synthesis is expected to be a disruptive technology replacing the need to find an open pharmacy. "

--
Much Madness is divinest Sense --
To a discerning Eye --
Much Sense -- the starkest Madness

Re:About CVS Only! Not SVN! by Dr_Barnowl · 2014-10-22 09:45 · Score: 1

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.

Re:About CVS Only! Not SVN! by DutchUncle · 2014-10-22 12:25 · Score: 1

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.

Re:About CVS Only! Not SVN! by cdecoro · 2014-10-23 04:10 · Score: 1

My apologies for my overly combative response. Thank you for your kind clarification.

Slashdot Mirror

Help ESR Stamp Out CVS and SVN In Our Lifetime

158 of 245 comments (clear)