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?
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.