Last week Denis Roy, the Eclipse webmaster, announced on the committers' mailing list that Eclipse has installed Subversion (SVN) and that Eclipse projects can make the switch from CVS to SVN if they choose. This leads naturally to the question should your project make the switch and, if so, is now the right time?Before undertaking a project such as migrating to SVN it's a good idea to perform a cost/benefit analysis. So let's start with that.
The following is my list of the key benefits of SVN (a more complete list is available from the SVN project website):
- File history is maintained even when files are moved or renamed. This means when Joe, a refactoring whiz, takes a cut at your code you'll still be able to view your comments to give you an idea of what's what. As anyone who's moved a file in CVS knows, when a file is moved in CVS its history is left behind and it's difficult if not impossible to locate later.
- Commits are atomic. This means a commit only succeeds if the entire commit succeeds. (CVS has a nasty habit of having part of large commits succeed.) It also means revision numbers and comments are applied uniformly across all of the resources that were committed. So the next time you do a large commit that fails in the middle you won't have to sync and manually figure out what still needs to be committed.
- Branching and tagging take a constant amount of time. This can make a huge difference when branching or tagging a large project and means you can continue to work instead of waiting for the operation to complete and possibly getting distracted by the latest argument on Slashdot.
- Someone will have to migrate your existing CVS repository to SVN. Although Denis has offered to help with the migration this will still require Egon, one of your project's developers and a member of the release engineering team, to spend time on migration, time he would otherwise have spent on activities that will affect the project deliverable like fixing medium and low priority bugs.
- Your project's developers will need to learn SVN if they're not already familiar with it. This may not seem like a big deal as SVN is very similar to CVS in many respects but it will take a non-zero amount of time, especially when installing (someone's bound to run into problems) and learning to use the tools (which are not the same as those of CVS), and again takes away Egon and other developers' time to fix those bugs.
- Furthermore, the current SVN tools for Eclipse are not available from Eclipse but from Tigris through the Subclipse project. Some employers have strict policies on using third party tools and Daina, a developer working on the 'cuddly' feature, may need to seek approval from her employer to use the available SVN tools. (There is currently a proposal for an SVN team provider project but that has not yet been approved.) This means Daina won't be able to contribute changes because she can't use these tools until they've been approved by her employer.
Let's take a look at one other aspect of this migration project. I've been reading Joel Spolsky's book Joel on Software so let's take a lesson from Joel and look at this change from a consumer (that's Eclipse user or adopter) perspective instead of a developer perspective. What will your consumers gain from the switch from CVS to SVN?
Nothing!
This switch will not reduce the development time, add more functionality, fix bugs, or improve the testing of your project.
So, to me this is now a question with a simple answer. No. It's not worth the time to make the switch from CVS to SVN now, in the middle of your development cycle, as this switch will provide very little benefit to your project. Also, this switch will not benefit your consumers who, in the long run, will determine whether or not your project is successful.
Are you saying no Eclipse project should ever switch from CVS to SVN?
No. I don't want to suggest that all the Eclipse projects should stay with CVS forever. As I listed above, there are benefits for developers in using SVN instead of CVS. These benefits do have an initial cost that I don't think is worth paying in the middle of a development cycle, given that there is so much more important development work to do, but may be worth paying at the beginning of a development cycle. Making the change at the beginning of the cycle will allow your team to respond to problems early and should mitigate schedule slips later on in the cycle when you have less flexibility. Also, if and when the SVN team provider project is approved and produces tools that come with Eclipse this will remove the third cost listed above. With this in mind, if your project does want to make the switch I'd suggest holding off on it until after Europa (the next Eclipse release train scheduled for June) or whenever your next major release happens to be.
Posts
9 comments:
In my (limited) experience, some of the Eclipse tools do not give the full benefit of what SVN is capable of. Moving files (at least, when creating patches as opposed to committing directly into a repository) doesn't seem to work, so refactoring often loses that information. It might be better if you're committing directly to a repository, but it's pretty bad (i.e. requiring you to do all your moves on the command line) in my experience.
One advantage that you didn't say is that SVN can also host connections over HTTP (see related bug). This would allow people to check out code -- which would encourage patches as opposed to just new code -- from corporate environments that have HTTP proxies but do not allow random TCP/IP traffic out. For example, I added a fix to allow members to be sorted as part of the CleanUp operation; but because I couldn't check the files out, I had to use the source bundled with Eclipse 3.3M4 SDK and add my changed files to the bug.
I agree with your conclusions; changing in the middle of a development cycle would be foolish for whatever reason, and that it's not going to make life much different now. But it does have some advantages for the future, and I'd expect SVN usage to continue to grow at the expense of other version systems (like CVS) in the future.
I'm pretty sure that some projects will start using it straight away, and after some experience has been built up, others may migrate; but it will be a long time before everyone is over (if ever).
I agree, Eclipse teams probably should not migrate to SVN until the team tools are right next to CVS. Having to rely on Subclipse or Subversive would undermine the self-hosting aspect.
That being said, I would be wary of the "what does the customer gain" argument. Basically, any change to the dev environment that improves productivity IS a customer gain. The SVN advantages you mention (better history searching, faster operation) are real productivity adds, not just geek toys. People will also be more willing to refactor when they know they won't mess up the history of changes. Bug history searching is much easier with the magic global revision number. In the long run, customers will notice.
Ironically Joel Spolsky did switch his source control over to SVN, so that was an odd argument to toss in there.
I have started a blog on Subversion and Subclipse, partly motivated to help people decide whether to make the switch. I have a couple of posts about the move/rename issue. See: http://markphip.blogspot.com/.
I agree projects should not move in the middle of a development cycle, that would be crazy for any project to consider. So for the main Eclipse projects, this should not be considered until after 3.3. One migration cost that you did not mention was just getting all those developer workspaces around the world switched over from CVS to SVN. I know when projects like KDE switched, that was one of the biggest issues to deal with. Migrating the repository with cvs2svn is a largely automated process. Someone has to run and monitor the progress of the script, but other than that it does not require a lot of user time.
I still do not get why the SVN plugins not coming from Eclipse is such a huge issue. What is so special about Eclipse? As the series of posts the last week that Bjorn began showed, the Eclipse Foundation does not direct projects. It is just what the developers and users contribute. What is the difference between the Subclipse team hosting a project at tigris.org versus eclipse.org?
I want to move Subclipse over to Eclipse.org because in the long term I think it provides more opportunity for the commonalities between CVS and SVN to be refactored into common API that other team providers can then use, creating a better API in the process. This of course will depend on our ability to work with the Team/CVS developers and get their support for the ideas.
Mark
More postives include a very well written book, good online communities and headache-free running of the system once its up.
You can visit this forum incase you have questions:
http://www.svnforum.org
Are there seriously employers that are progressive enough to pay people to contribute to open source projects like Eclipse, while at the same time preventing these ace programmers from using Subversion? I'm not buying it. In my experience companies that are so restrictive as to prevent you from installing open source tools are probably not going to be contributing back to open source projects in the first place. Likewise, companies actively contributing to open source probably don't have a problem with their programmers using other open source projects.
To echo the previous comment, it would also not make sense for an employer to be OK with you using Subversion (which comes from tigris) but not Subclipse (because it comes from tigris).
I am the Subclipse project lead, and a Subversion committer and I have another Subversion committer that works with me. Why would one be OK but the other not?
Having been a former IBMer, I know why they don't like people using random open source software. It all has to do with IP cleanliness. Eclipse offers certain guarantees that software downloaded from Eclipse has been checked and that putting it on an employees machine will not "pollute" their environment. It's a bit twisted since the conjecture is that having open source software on you machine means there is a chance you'll look at it and stick it into your proprietary code. But it is how these companies run and why Eclipse's IP policies are so important.
BTW, I believe Subversive has been approved as an Eclipse project. During the review I made it clear that Eclipse can only support one client at the end of the day and that the Subversive and Subclipse teams need to work together. For the good of all Eclipse SVN users.
Sod the costs!
Sometimes we need dictatorship to take us into the future and all this playing around with ideas is nonsense.
To the future comrades. Choose SVN!
Svn is really amazing and so is WTP. But the one gripe/warning i think svn newbies should heed to is to be uber careful before using svn remove.
Call me an idiot, but i believe that a versioning system should recognize that the operating system shell provides an "rm" or "remove' command should a user want to "delete" his local file. Svn remove will tell you that you must use --force to actually remove a file from subversion, but what it does not tell you is that it will nuke the local copy too. I've been burnt by this and feel like this is worth bringing up when people talk about the relative merits/demerits of svn.
Post a Comment