Sunday, May 27, 2007
subversion: overdue good-bye?
I discovered subversion before it got to 1.0. I convinced people working with me then to switch. At that time we were using ClearCase. Simplicity and speed of subversion was in comparison exhilarating. I even wrote couple of simple ruby scripts to bridge official ClearCase and our subversive repository. Even the name was perfect. Let's just say that even my undeniable sense of humor and personal charm failed to mend strained relations with Release Engineering group (yeah - it was a big company).
When I started working in Pingtel sipx developers already had been using subversion. Since it was about the time we needed to create our first real branch I took upon myself figuring out how to use svnmerge. We never looked back.
If that was not enough Producing Open Source Software that Douglas made me read at one point practically defined the way I think about my job. And it's written by Karl Fogel - yes - the subversion Karl Fogel.
I am writing all that to prove that I really like subversion. So it saddens me to realize that my favorite tool is most probably no longer the best tool.
As a part of my daily job I am committing patches sent by contributors. From time to time I create branches for people who want to experiment with sipx without breaking mainline. And slowly I begin to think that my job would be easier with a different tool. And that with a different tool sipXconfig and sipx would get more contributions and better contributions.
With subversion - or any other centralized SCM - there are always two categories of people: those with commit access and everybody else. Committers and patch senders. In-crowd and followers. Eloi and Morlocks.
As a patch sender you have to create your working copy, make your changes, send the patch - and - never use this working copy again. At least not until someone with commit access actually commits your patch. If the patch gets not accepted in its original form and you want to fix it, you are losing the history. You cannot somehow save your changes locally and than make changes on top of your changes. At least if you only have one patch you can keep updating the working copy and track the mainline. If you have more than a single patch however you are doomed. Subversion does not make life easy for you. I wonder how many useful contribution sipx is losing just because it's too hard to contribute anything more than a simple patch.
But even once you get commit access the problems do not stop. Before you get commit rights your every step is watched, every patch reviewed, every extra space corrected. Once you do not have to send patches for approval anymore it changes. It's not about becoming sloppy. It's about the lack of feedback. Even if someone does review your commits, and people do, once you check something in, it's in. Official. With good chances to survive forever without being looked at. One of the biggest benefits of open source, constant peer code review, is not the default option.
I started thinking about it after reviewing several patches last week. I took some. I rejected some. I sent comments or my own fixes on top of those patches for review. I knew what I was doing with subversion all the time but somehow it felt like I am working around my SCM rather than using it.
I thought of darcs which I discovered when trying out buildbot (sipx nightlies are courtesy of buildbot). That lead me to git, mercurial and others. It quickly became obvious I was not alone. Mozilla chose Mercurial over Bazaar (both distributed). They did not even shortlist subversion. Linus with his usual flair refers to subversion as the most pointless project ever started. He has a point. Open source project should never use anything but distributed SCM.
Source Control Management history follows the script leading to more freedom to modify and experiment: "lock-modify-commit" gets replaced by "copy-modify-merge-commit" (no locking) which in turn morphs into "pull-modify-commit-push" (no central repository).
If only I could figure out how this tailor thing works, I would set up mercurial mirror of sipx and encourage contributors to use it. Exciting.
When I started working in Pingtel sipx developers already had been using subversion. Since it was about the time we needed to create our first real branch I took upon myself figuring out how to use svnmerge. We never looked back.
If that was not enough Producing Open Source Software that Douglas made me read at one point practically defined the way I think about my job. And it's written by Karl Fogel - yes - the subversion Karl Fogel.
I am writing all that to prove that I really like subversion. So it saddens me to realize that my favorite tool is most probably no longer the best tool.
As a part of my daily job I am committing patches sent by contributors. From time to time I create branches for people who want to experiment with sipx without breaking mainline. And slowly I begin to think that my job would be easier with a different tool. And that with a different tool sipXconfig and sipx would get more contributions and better contributions.
With subversion - or any other centralized SCM - there are always two categories of people: those with commit access and everybody else. Committers and patch senders. In-crowd and followers. Eloi and Morlocks.
As a patch sender you have to create your working copy, make your changes, send the patch - and - never use this working copy again. At least not until someone with commit access actually commits your patch. If the patch gets not accepted in its original form and you want to fix it, you are losing the history. You cannot somehow save your changes locally and than make changes on top of your changes. At least if you only have one patch you can keep updating the working copy and track the mainline. If you have more than a single patch however you are doomed. Subversion does not make life easy for you. I wonder how many useful contribution sipx is losing just because it's too hard to contribute anything more than a simple patch.
But even once you get commit access the problems do not stop. Before you get commit rights your every step is watched, every patch reviewed, every extra space corrected. Once you do not have to send patches for approval anymore it changes. It's not about becoming sloppy. It's about the lack of feedback. Even if someone does review your commits, and people do, once you check something in, it's in. Official. With good chances to survive forever without being looked at. One of the biggest benefits of open source, constant peer code review, is not the default option.
I started thinking about it after reviewing several patches last week. I took some. I rejected some. I sent comments or my own fixes on top of those patches for review. I knew what I was doing with subversion all the time but somehow it felt like I am working around my SCM rather than using it.
I thought of darcs which I discovered when trying out buildbot (sipx nightlies are courtesy of buildbot). That lead me to git, mercurial and others. It quickly became obvious I was not alone. Mozilla chose Mercurial over Bazaar (both distributed). They did not even shortlist subversion. Linus with his usual flair refers to subversion as the most pointless project ever started. He has a point. Open source project should never use anything but distributed SCM.
Source Control Management history follows the script leading to more freedom to modify and experiment: "lock-modify-commit" gets replaced by "copy-modify-merge-commit" (no locking) which in turn morphs into "pull-modify-commit-push" (no central repository).
If only I could figure out how this tailor thing works, I would set up mercurial mirror of sipx and encourage contributors to use it. Exciting.
Powered by ScribeFire.
- posted by Damian @ 6:58 AM
| permalink
Comments:
<< Home
Actually, I suspect Subversion will gradually start growing distributed features (starting, most likely, with full client-side repositories to manage the working copies). Subversion was really designed around tree management, not centralization; the centralization isn't inherent in its design, it's just what we knew and what we aimed for 1.0 to ship with. Many (though not all) Subversion developers I talk to see the value of adding distributedness.
I don't feel the situation is quite as black-and-white as you paint it (Subversion seems to be working out pretty well for a lot of open source projects), but in the long run basically agree: distributed is the way to go.
However, why are you having trouble getting change review after someone has commit access on the central repository? Commit emails with diffs are easy to set up, and there are other review systems out there too (see http://code.google.com/p/gvn/, for example). And, if you have time, could you explain in more detail how review is easier with the distributed systems than with Subversion? I wasn't quite clear on how distributedness helped there.
I don't feel the situation is quite as black-and-white as you paint it (Subversion seems to be working out pretty well for a lot of open source projects), but in the long run basically agree: distributed is the way to go.
However, why are you having trouble getting change review after someone has commit access on the central repository? Commit emails with diffs are easy to set up, and there are other review systems out there too (see http://code.google.com/p/gvn/, for example). And, if you have time, could you explain in more detail how review is easier with the distributed systems than with Subversion? I wasn't quite clear on how distributedness helped there.
I meant to say also: thanks for the kind words about the book! I'm glad you liked it.
I've been keeping Appendix A ("Free Version Control Systems") up-to-date with what seems to be happening out in open-source land, so recently I moved SVK, Mercurial, and GIT to be up near the top of the list, as they seem to be getting more popular (although it's not clear whether their adoption rate is growing as fast as Subversion's, which is at the top of the list, and of course the usual caveats about popularity contests and feedback loops apply).
I've been keeping Appendix A ("Free Version Control Systems") up-to-date with what seems to be happening out in open-source land, so recently I moved SVK, Mercurial, and GIT to be up near the top of the list, as they seem to be getting more popular (although it's not clear whether their adoption rate is growing as fast as Subversion's, which is at the top of the list, and of course the usual caveats about popularity contests and feedback loops apply).
And yet a third comment...
You wrote "Committers and patch senders. In-crowd and followers. Eloi and Morlocks." about the distinction between committers and non-committers. I think that's missing the real distinction.
The question is not whether you can commit to some repository somewhere (an SVN user can set up a local SVK repository, for example; and actually we've given non-committers branch commit access in Subversion's own repository before, for experimental work).
The real question is: who is authorized to put changes in a place where they're destined to be in the public releases by default? That's the real power distinction, if there must be one. Whether this is enforced through commit access, or push/pull access, or something else, doesn't matter. The distinction is essentially social, not technical, although technical means may be used to enforce it more or less conveniently. It's about governance: who decides what changes are accepted, and whose changes are being decided on. There are lots of different social structures for answering that question.
You wrote "Committers and patch senders. In-crowd and followers. Eloi and Morlocks." about the distinction between committers and non-committers. I think that's missing the real distinction.
The question is not whether you can commit to some repository somewhere (an SVN user can set up a local SVK repository, for example; and actually we've given non-committers branch commit access in Subversion's own repository before, for experimental work).
The real question is: who is authorized to put changes in a place where they're destined to be in the public releases by default? That's the real power distinction, if there must be one. Whether this is enforced through commit access, or push/pull access, or something else, doesn't matter. The distinction is essentially social, not technical, although technical means may be used to enforce it more or less conveniently. It's about governance: who decides what changes are accepted, and whose changes are being decided on. There are lots of different social structures for answering that question.
Hey, I am consulting for a company doing a sipxecs based product. Since the comapny has quite a distributed team and they can't commit back to svn, I have setup a Mercurial repository for them to work on. I created the repository using HGSVN so we keep pulling changes from sipx repository and also developer keep bringing in code time to time after working on their local hg branches for various features and then commiting back to the HG repo on our server.
I can help in any way required to get a official HG repo setup which will keep in sync with the SVN repo.
Post a Comment
I can help in any way required to get a official HG repo setup which will keep in sync with the SVN repo.
<< Home
