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.
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.)
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.
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):
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.
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?
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. :)
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.
Agree 100%. Two anecdotes that show how far we've come in the last few years:
* Working on my laptop on the train the other morning I cd'd into an old source tree that was checked out from subversion a few years ago. I was brought up short by subversion not being able to tell me the revision history, what with it being unable to connect to the repository server.
* I also recently needed to checkout an old version of Rails using a rake task I wrote a few years ago, and discovered that Rails subversion repository has gone away. The revision history has moved across to github, but scripts will have broken and existing subversion checkouts will have lost their history.
If you go with a centralised VCS, you will get burned at some point by being unable to connect to a repository, either temporarily or permanently.
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.
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.
I think the problem you need to tackle is not whether your source control system can scale to handle your huge project as a single entity, but whether your whole development process is being hampered because you're looking at it that way. I would recommend you break your system down into a number of separate modules and manage them separately, giving the modules their own release schedules and properly managing the dependencies between them. "The granule of reuse is the granule of release" [1], so if you don't have a formal release process around individual modules, you can't reliably reuse them. If you do that you can create separate repositories for each module, and you'll then find that your branches are more tightly scoped (to a single module), merges are simpler as a result, volume of change is localised to the less stable modules and weird file types can be restricted to specific modules.
Once you've refactored your codebase you'll be in a position to make better choices about a source control system.
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.
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?
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.
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.
21 comments
[ 2.9 ms ] story [ 38.2 ms ] threadThe 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.
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.
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.
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.
And for actual software development, as I said, we do use Git. :)
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.
* Working on my laptop on the train the other morning I cd'd into an old source tree that was checked out from subversion a few years ago. I was brought up short by subversion not being able to tell me the revision history, what with it being unable to connect to the repository server.
* I also recently needed to checkout an old version of Rails using a rake task I wrote a few years ago, and discovered that Rails subversion repository has gone away. The revision history has moved across to github, but scripts will have broken and existing subversion checkouts will have lost their history.
If you go with a centralised VCS, you will get burned at some point by being unable to connect to a repository, either temporarily or permanently.
might be relevant: http://stackoverflow.com/questions/3320001/source-control-sy...
Thanks.
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.
Once you've refactored your codebase you'll be in a position to make better choices about a source control system.
[1] http://www.objectmentor.com/resources/articles/granularity.p...
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.
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.