Why Subversion Scares Me | Hacker News Reader

Why Subversion Scares Me

git-tower.com

11 pointsdpree15 comments

This article is idiotic and is clearly written by someone who doesn't understand Subversion.

You work on feature branches, then merge them into trunk. Only at the point of that merge are you sharing changes with everyone. But at any time, everyone can see your private branch, centrally.

Committing infrequently is a problem with not using branches properly. I commit to an SVN repository up to 50 times a day without forcing my code on anyone.

Merges aren't any scarier than they are in Hg/Git either despite common belief.

All VCS problems are usually external to the VCS i.e. human or process issues.

Edit: I just noticed the author is pushing a Git client. need we say any more.

I haven't used SVN in about 2 years, but when I was using it I remember branching taking about 10minutes. It had to redownload the entire working directory again I believe, which made it essentially pointless - I only branched when I was going to be doing a huge amount of work.

Have they fixed that?

Creating a branch is instant (well < 5 seconds).

Switching branches depends on how much change there is between the previous branch and the one you are switching to. It basically sends all the files that have changed. On our solution which is about 120,000 files, it takes about 10-25 seconds on HTTPS/WebDAV protocol.

It's fast enough. I switch probably 2-3 times a day.

You can check each branch out separately if you want but this isn't necessary and probably is the cause of the pain you had.

I think you must have been doing it wrong, because I don't think this has ever been the case. In any event, it's plenty fast now: the branch is a "copy" operation on the server (which takes no time since Subversion does everything as copy-on-write) followed by re-pointing your local copy. Since there are no changes, it fetches no new data.

> This article is idiotic and is clearly written by someone who doesn't understand Subversion.

Or maybe you don't understand what the article is about.

> You work on feature branches, then merge them into trunk. Only at the point of that merge are you sharing changes with everyone.

> Merges aren't any scarier than they are in Hg/Git either despite common belief.

This is the theory, but in practice I haven't seen SVN people doing it, I once worked for a company that had SVN and told the people that we should do feature branches, and the lead developer instantly rejected it, because it is too hard to merge.

So either 99% of the people don't know how SVN works or branching is simply too damn hard in SVN.

> Merges aren't any scarier than they are in Hg/Git either despite common belief.

> All VCS problems are usually external to the VCS i.e. human or process issues.

A lot of major projects switched to git from SVN, so either the are all "idiots" or they had a real issue with it.

Even if all VCSes are equal as you say, the fact that people lack the mental capacity to comprehend the greatness of Subversion makes it inferior to Git.

> In newer versions of SVN, you could create feature branches to circumvent this. However, it remains a workaround, not a true local commit like in a distributed VCS like Git.

While I do prefer the Git approach to version control, it is too easy to just dismiss branching as a "workaround". It is a good solution to the discussed problem.

Agreed. Subversion branching is a direct solution for both problems he mentioned in the article.

I'm not sure the author of this article understands subversion branching [1]. As long as you are not making a commit to the master trunk, you will not be interfering with other developers on your team. The author dismisses SVN branches as a "workaround", when it solves all of the "scary" SVN issues he discusses in the article.

http://svnbook.red-bean.com/en/1.1/ch04.html

Also, if you're working on small parts and ensuring that no tests fail/writing adequate tests, it's not so bad. Our 30-member team isn't hampered by it while we await changes next year.

Although our team uses git for code we actually use SVN as part of some of the applications we have built - end users (who are not developers) can upload report designs which are Excel spreadsheets using TortoiseSVN and the development reporting application instance picks the latest version from the SVN server - works a treat and users get versioning, diffs and an easy upload process.

Diffs? Can you diff excel files somehow?

TortoiseSVN by default tries to get Excel to do a diff (which it's not great at) - you can configure it to use a 3rd party Excel diff tool.

The problem isn't distributed vs. centralized commits, it is infrequent and large commits vs. regular and smaller commits.

The fact that Subversion does that in one step, compared to two steps in Git doesn't really matter.

In some ways Git makes the problem of large, infrequent commits worse because of the ability to track local commits.

Counter-argument:

http://www.codinghorror.com/blog/2008/06/dont-go-dark.html

This is stupid. Keeping code to yourself for long periods of time is a problem. It's still a problem even if you're regularly making commits locally and just not pushing them.

You're afraid to push changes because other people might see how bad your code is? Either write better code or grow a thicker skin, or both.

The fact that many people embrace this secretive, private way of using version control scares me, and it's this sort of nonsense that causes a lot of old-school programmers to be skeptical of systems like git.

Reply on news.ycombinator.com