

The Subversion Mistake - latchkey
http://lookfirst.com/2011/04/subversion-mistake.html

======
abalashov
Eh. There's no reason to be dogmatic about Subversion vs. Git, or centralised,
CVS-style VCSs vs. DVCSs in general. Use the right tool for the job.

While I don't disagree with the author's assertion that Git would much better
support the kind of workflow he described, I think it's going a little far to
categorically deem Subversion a "mistake" in all situations, 100% of the time.
Subversion's relative simplicity compared to Git, as well as the toolchains
built around it, hold a lot of appeal for certain applications.

For instance, we are a telephony consultancy that provides a lot of backend
operational support to VoIP service providers. We did switch to Git for
internal code development, but as part of most of our daily bread, we do a lot
of configuration and provisioning changes to customer network elements, and we
use Subversion for that because it's absolutely perfect. Managing
configuration changes--even pseudo-programmatic ones--is a natural fit for
Subversion, in the sense that a commit is simply a log of the cumulative
effect of changes since the last commit, a statement about change that has
taken place in a particular interval of time.

This type of management does not typically require branching, complicated
merges, etc. The goal is simply to keep a running archive of configuration
snapshots. Doing all that with Git, with its two-stage commit process (if you
intend to use it in a centralised way) and rather inferior stock post-commit
hook scripts wouldn't be worth the pain. Plus, in configuration management
it's really helpful to be able to refer to revision 346 on an emergency
conference call for a phone switch outage at 3 AM, rather than a long digest
string.

Use the right tool for the job. There are relatively few things that are
unequivocally "mistakes." A great deal of what passes for "factual" evidence
in support of tool dogma is rooted in the forces of custom, habit and culture.
There's nothing wrong with that; it's just something that should be kept in
mind.

~~~
pyre

      > rather than a long digest string
    

A bit of a nit, but git does allow a shortened SHA-1 form.

~~~
abalashov
Yeah, but it's still pretty hard to say in a meeting: "If you look at the
differences between commits 0ab49c and b6ffd3 you'll see the problem."

------
patio11
Previous svn user, now happy git user: if you have the choice for greenfield
dev, user git, hg, or any other DVCS. The advantages to doing so are
_enormous_. It will likely require changing your workflow at the commit,
branch, and merge levels (you'll do a lot more of all three), but after you
adjust, particular things which once caused workweeks of loss simply _don't
happen_.

SVN is wonderful software. It is a quantum leap above "no version control" and
tortoiseSVN is probably the best GUI available for getting value out of
version control prior to understanding it. That said, magical goodness awaits
you if you use DVCS instead.

~~~
raghava
I have this question for every proficient DVCS user. Would it scale? When I
say scale, I refer to a codebase running into lakhs of sources with a minimum
of 20 filetypes including binary types, and at anytime more than 30 active
branches, with frequency of merges/recons being one every week, and average
volume of change in a source being 150 SLoC. I ask because am still unable to
find a definitive answer and I want to know the things I might end up with, if
I attempt migrating such a codebase from CVS to a DVCS like git/Mercurial.

might be relevant: [http://stackoverflow.com/questions/3320001/source-control-
sy...](http://stackoverflow.com/questions/3320001/source-control-system-for-
not-so-smart-programmers)

Thanks.

~~~
patio11
Just an FYI: most folks on the Internet don't use lakhs as a unit. The only
reason I know what you mean is because I managed Indian outsourcing operations
for a while. (FYI for everyone else: lakhs means 100,000 and a crore is 10
million.)

I don't have your problems with source control. The Linux project probably has
somewhere in the neighborhood of that, and since git was built for Linux, I
would not bet on it being architecturally impossible for git to scale that
far. The more serious problem I see coming down the pipe is getting your
entire team to adopt DVCS workflows. For example, you'll probably end up
moving away from having one person whose sole job is making sure merges don't
explode into firey balls of death. Distribution of responsibility for making
merges happen well could, conceivably, cause problems for a segment of your
developers.

------
latchkey
Hi HN. Great responses.

The reason for the title of my posting is not to call 'Subversion A Mistake.'
It was because of something Linus said in his video (which I highly recommend
you watch). Basically, what he said is that if you can't trust your VCS to
have the code in it that it should (and verifiable via hashes), then that is
everything. I agree.

The Subversion Team, who are all great people and _really_ smart, made a huge
mistake with adding mergeinfo to 1.5. It is a trainwreck of pretending to be
able to do merges reliably, but in reality, it plain doesn't work. I talk
about two specific cases where it breaks down in my posting, but there are
many more.

Subversion has a lot going for it, I just think that the mergeinfo feature
should just be thrown out and reworked from the ground up. My guess is that it
will never happen as people will move on to newer and better systems, like
git.

------
andos
What made our migration from CVS to Git a breeze was using Gitorious. It
helped that our team was very supportive of Git, but Gitorious alleviated the
shock of going from centralized to distributed. Our server guy had a hell of a
hard time making Gitorious work, though.

------
pkteison
It seems to me like git and mercurial both solve this problem, but picking one
is a big choice with lots of hard to evaluate impacts. Is doing a weekend
project on each enough exposure to make a good decision? If not, any other
suggestions?

~~~
parfe
Doesn't matter which one you pick. They both do the same stuff.

If Svn is an orange then Git is a Granny Smith Apple, and Hg is a Golden
Delicious. Just comes down to a personal flavor preference. I prefer git based
on nothing more than feeling. If you pick one I highly doubt you'll have
regrets. Hell, you might even want to pick based on BitBucket vs GitHub.

------
silon
In subversion, it's best to rebase the branch after you have merged it back.
Just like git rebase, you lost history.

------
dlsspy
"Let's build a better Pinto."

------
bluedanieru
We tried this exact formula at a place I worked previously and we had mostly
the same results. It didn't help that the guy in your position didn't know the
codebase or Subversion very well either. It was/is terribly painful and
indicative of brain-dead managers and along with a few other (admittedly more
important) things eventually led me to quit.

The most frustrating aspect was it seems that, while far from perfect, using
Subversion as intended, in your case and ours, would be 1/10th as painful even
while introducing a few issues of its own. The explanation I always got was
"long before you came on board we used Perforce but we switched to Subversion
because it's open source but we still want to use it like it's Perforce." You
seem to have reasoned about your change quite a bit more than this, so I'm
interested in hearing why you think you need to do things this way.

~~~
spullara
While reading this it struck me as well that he was describing a perforce
workflow, not subversion.

~~~
bluedanieru
I didn't know Perforce at the time so I couldn't comment. I learned it later
on which helped to understand that side of it. Still doesn't explain why they
thought they can switch to a different tool but continue the same workflow as
with the previous tool. (I can certainly explain that part but it would be out
of context here, heh.)

