Live data from Hacker News

It’s time to stop using Subversion

altdevblogaday.org

31–40 of 112 posts

Re: It’s time to stop using Subversion

#31
post #18

As someone who got started in this field about 10 years ago, I find the mass-adoption of and then mass-exodus from subversion fascinating. I remember sitting in the audience for a talk by Greg Stein introducing subversion at ApacheCon ('02 maybe) and being wow'ed. I'm trying to think if there's another piece of architecture our industry has both so universally embraced & discarded (hyperbole, I know) in the last deca…

It's because 10 years ago there weren't really any distributed version control systems, and the original aim of Subversion was to fix everything that was horribly broken in CVS. They definitely succeded with that design goal, but since they're stuck in a centralized design, there's nothing they can do to move it to a distributed model, and it's not something that could have been foreseen 10 years ago. They're simply…

I think that's the best position (in case of svn) to be in.

Subversion is, imho, the best of centralized scm-s. There are many companies that, for some reason or other, will not switch to dvcs. It really doesn't matter that distributed model is better than centralized, some people will not switch over. And svn is great choice for them.

Re: It’s time to stop using Subversion

#32

I'm kinda annoyed that every once in a while, somebody has to come along dissing svn, prophesying its inevitable demise and glorifying git. Yes, git is "better" than svn, I agree. I like the message in general, but I don't like the tone of it. I still use svn. For personal project, I have moved to hg. I use git occasionally. They all have its merits, and svn certainly didn't deserve "you should probably stop using it…

It seems to me that a lot of the evangelists of one source control tool over another fail to realize that for companies that -aren't- startups, migrating between tools is a lot of work. Reconfiguring build servers, rewriting documentation/wiki pages which have SVN Uris (or anything at all regarding existing source control) in them for projects that have existed 5-10 years as well as having an entire team learn a new…

Exactly!

I have 15 GB of svn repositories. I don't plan to migrate them. I use mercurial for new projects and I'm fine with old stuff to live in svn.

Just like I use more than one programming language, I use more than one OS, I use more than one database backend...

Re: It’s time to stop using Subversion

#34
> If I'm committing some large assets...

(Isn't version control mostly for text files?)

> If, while the upload's been happening, I've made more changes to my working copy...

(So you're uploading a large--presumably binary--file, and you're continuing to work on it while it's committing...)

> I have to carefully pick out my new changes and keep them separate from my old changes.

(Wait, what? In a binary file? Or did you commit the binary file and changes to smaller text files in the same changeset? If so, you should be committing them separately. Either you're making small commits to text files that commit almost instantly, or you're making large commits to binary files that you can't "pick out" changes from anyway. Gotta pick one.)

> As soon as the commit is published, other people may check it out and try building it...

> ... if I can't access the repository server – if it's gone down, or if I'm working remotely – then I can't commit at all.

> ... but there are many reports [weasel words] of it being somewhat prone to error. If your mergeinfo property has been corrupted somehow, it might be extremely hard to spot...

I see a lot of inconclusive beating around the bush here. The author doesn't want to come out and say that any of these are concrete showstoppers because they are all, at worst, edge cases that experienced svn users mostly know how to deal with anyway. Every VCS has its own bugbears like these, git included.

I have been using subversion for years; I do all kinds of insane nonsense with private branches, merging and merge-tracking, large asset commits and all of the things this article uses for its doomsaying. I run into big problems maybe two or three times a year.

The writer suggests that git is better.

For some reason, even though I have read numerous manuals and guides about git, and have grilled git experts, and have regularly used git myself, and presumably understand how it works, I have to go on a farcical journey into its implementation details every time I do ANYTHING. I always end up in #git, or calling a more git-savvy friend. Everyone inevitably has a different answer that involves a lot of shrugging and "Oh, I guess this actually happened." This was the result even when all I did was follow the instructions at help.github.com/forking, TO THE LETTER.

Perhaps I am just a moron, and subversion is just VCS for morons. If so, I am too far gone to realize.

Re: It’s time to stop using Subversion

#35
post #11

Do not confuse elitism with minimalism. Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). When branching in git is a simple git checkout -b newbranch away as opposed to svn copy http://repo.com/some/path/to/trunk http://repo.com/some/path/to/branches/somenewbranch - then what el…

[deleted]

Re: It’s time to stop using Subversion

#36

I'm kinda annoyed that every once in a while, somebody has to come along dissing svn, prophesying its inevitable demise and glorifying git. Yes, git is "better" than svn, I agree. I like the message in general, but I don't like the tone of it. I still use svn. For personal project, I have moved to hg. I use git occasionally. They all have its merits, and svn certainly didn't deserve "you should probably stop using it…

It seems to me that a lot of the evangelists of one source control tool over another fail to realize that for companies that -aren't- startups, migrating between tools is a lot of work. Reconfiguring build servers, rewriting documentation/wiki pages which have SVN Uris (or anything at all regarding existing source control) in them for projects that have existed 5-10 years as well as having an entire team learn a new…

In my experience, going from SVN to Git has been as simple as doing git-svn clone and then pushing up to Github (or Assembla). Then again, I agree that there's a lot for the users to learn, so it's probably best done during a refactoring phase and you need at least one Git master to be available to answer any questions.

Re: It’s time to stop using Subversion

#37
post #27

Earlier quoted context omitted.

"someone always has it worse." Unfortunatelly, not in your case. ;)

What was the name of that version control tool before CVS, RVCS? Back in 2007 I had heard one very big name hardware company using that for version control and planning to move to CVS as they thought the former was beginning to show its age.

Or you could talk to Joe down the hall. He has the 'gold' version of the source code on his desktop. Don't forget to send him your changes when you are done and he will integrate it to the current 'gold' version.

Re: It’s time to stop using Subversion

#38
post #29
post #20

Earlier quoted context omitted.

> Git is simply easier to use, and harder to shoot yourself in the foot with - at least when it comes to the basic flows. (Granted, you can blow your face off with git if you really try hard). I don't know. I've trained a lot of developers with Subverison, Git, and Mercurial. Subversion is the one that I've honestly had the least trouble with, and Git the most. Heck, early on with git I had instances where the repo w…

It sounds like you were training people on git when you didn't know git very well. That's an odd way to judge git.

Not if he put equal amounts of effort into learning git, svn and hg.

Re: It’s time to stop using Subversion

#39

Having just spent the last month converting our operation to Git here at work, I can tell you the main force in keeping Subversion around are Windows users who are used to TortoiseSVN. There still is no viable Git UI for Windows (or any other OS, really -- but Windows is especially immature) and the people who make decisions a) use Windows and b) "don't have time" to learn git on the command line.

How about TortoiseGit? http://code.google.com/p/tortoisegit/

After spending days helping people recover from fetch/rebase and merges gone bad, I advise people to stay away from TortoiseGit altogether. Also, TortoiseGit makes no attempt to let Git's simplicity shine through. Why show a dialog box with a huge number of options when all I have to do at the command line is type "git commit -m'Foo'"?
Post reply on HN