4 ms·

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 d

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 16y ago
> rather than a long digest string A bit of a nit, but git does allow a shortened SHA-1 form.
- abalashov 16y ago
  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."
darklajid 16y ago
I agree that it is useless to bash subversion: I know lots of business that still run it and are happy users. I tend to support the article's claim that agile and distributed (d'oh..) development suits the git/bazaar/mercurial model more, but that's no reason to denounce the subversion project as a single 'mistake'. Regarding the long string vs. revision though: That's the reason you'd usually refer to a named thing (tag, head of branch) + a qualifier. Using gitosis as an example repository (just had a clone of it around): $ git describe 73a032520493f6b4186185d4826d12edb5614135 release/0.2-47-g73a0325 $ git name-rev 73a032520493f6b4186185d4826d12edb5614135 73a032520493f6b4186185d4826d12edb5614135 master~2 i.e. that commit is 47 commits after the commit referenced as release/0.2 and 2 before master.
abyssknight 16y ago
This is exactly what I came here to say. Thank you for saving me the time, and doing so far more eloquently than I would have. Using the correct tool for the job is the only thing that matters in this situation; dogma is the bane of productivity. As an anecdote, I once knew a budding developer who insisted we use Gentoo for our new phone system. He recompiled the phone system at least 5 times a day. We had it stable for a week when he decided we needed to upgrade the kernel and all of the packages. We lost everything, and the owner of the company demanded we use Fedora going forward. We never did stand up that VoIP phone system in the time I worked there. The right tool is the one that works. Sometimes we forget that. Some of the most popular web applications and start ups we know and love were built on the platforms we adamantly ridicule and despise.
prodigal_erik 16y ago
I'm having trouble even imagining an environment in which I could do reliable work without branches (and I say that as part of a team that was continually screwed by svn's dangerously brittle merge support). How do you handle parallel development or testing changes?
- abalashov 16y ago
  In a small consultancy model, having two or more people work on the exact same parts of a configuration or build tree for a customer is very improbable. And for actual software development, as I said, we do use Git. :)

pyre 16y ago

> rather than a long digest string A bit of a nit, but git does allow a shortened SHA-1 form.

abalashov 16y ago
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."

darklajid 16y ago

I agree that it is useless to bash subversion: I know lots of business that still run it and are happy users. I tend to support the article's claim that agile and distributed (d'oh..) development suits the git/bazaar/mercurial model more, but that's no reason to denounce the subversion project as a single 'mistake'. Regarding the long string vs. revision though: That's the reason you'd usually refer to a named thing (tag, head of branch) + a qualifier. Using gitosis as an example repository (just had a clone of it around): $ git describe 73a032520493f6b4186185d4826d12edb5614135 release/0.2-47-g73a0325 $ git name-rev 73a032520493f6b4186185d4826d12edb5614135 73a032520493f6b4186185d4826d12edb5614135 master~2 i.e. that commit is 47 commits after the commit referenced as release/0.2 and 2 before master.

abyssknight 16y ago

This is exactly what I came here to say. Thank you for saving me the time, and doing so far more eloquently than I would have. Using the correct tool for the job is the only thing that matters in this situation; dogma is the bane of productivity. As an anecdote, I once knew a budding developer who insisted we use Gentoo for our new phone system. He recompiled the phone system at least 5 times a day. We had it stable for a week when he decided we needed to upgrade the kernel and all of the packages. We lost everything, and the owner of the company demanded we use Fedora going forward. We never did stand up that VoIP phone system in the time I worked there. The right tool is the one that works. Sometimes we forget that. Some of the most popular web applications and start ups we know and love were built on the platforms we adamantly ridicule and despise.

prodigal_erik 16y ago

I'm having trouble even imagining an environment in which I could do reliable work without branches (and I say that as part of a team that was continually screwed by svn's dangerously brittle merge support). How do you handle parallel development or testing changes?

abalashov 16y ago
In a small consultancy model, having two or more people work on the exact same parts of a configuration or build tree for a customer is very improbable. And for actual software development, as I said, we do use Git. :)