

Why Subversion Scares Me - dpree
http://www.git-tower.com/blog/why-subversion-scares-me/

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

~~~
shawabawa3
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?

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

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

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

------
prg318
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](http://svnbook.red-
bean.com/en/1.1/ch04.html)

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

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

~~~
wlievens
Diffs? Can you diff excel files somehow?

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

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

------
Pxtl
Counter-argument:

[http://www.codinghorror.com/blog/2008/06/dont-go-
dark.html](http://www.codinghorror.com/blog/2008/06/dont-go-dark.html)

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

