CVS to SVN Conversion
Recently We wanted to have more flexibility in our release process and already facing problems with CVS while renaming files or moving files I decided it was time to convert to Subversion. So I did a quick evaluation and found that the change was compelling and would really help us. I am listing out some of the reasons for our change
1. Atomic commits.
2 CVS maintains the file level versioning whereas SVN maintains a project level versioning. We get the changeset of what files were changed in a particular commit without the hacks of same time commits as in CVS.
3 Braching and tagging are now a O(1) operation than O(n) as it was in CVS. For us we do a lot of releases and tagging and branching operations were quiet often and we used to wait for 10-15 mins for it to complete. Now it just zips fast.
4 File renaming and even directory level tracking. (This is one feature for which I would definitely change. We do a lot of refactoring and it was causing us loose history in cvs and now its like a breeze)
5 Better handling of the binary files. We maintain a lot of word doc and if some users forget the -kb switch we were really loking for a trouble in cvs.
6 Better network usage. Some of the operations like diff, revert, status can be done without the network so it makes your job easy to carry work home and work without the repository.
7 separation of update and status clears a lot of confusion and you can update the code only when you need it not to look at the changes made.
8 Properties handling is much cleaner way of storing associate information.
9. Undoing changes made in a single changeset is much easier than rolling back at each file level.
Ok I think we are convinced that SVN gives better facilities than CVS. Now coming to moving of the repository we would like to maintain the history of the repository. There are a couple of ways of doing it
1. To get the latest source code imported to SVN and maintain the CVS as a readonly repository for previous history.
2. Use cvs2svn or there are a couple of more scripts available to convert your cvs repository to SVN repository. They convert your branches, tags and group the changesets based on the time of commit. My version of CVSNT I had was 2.0.51d. I downloaded CVS2SVN 1.3 version and started my conversion.
CVS2SVN conversion program doesnt work on Windows environment. I downloaded the cygwin library and ran the python script from cygwin and boom the repository got converted. I had to do some tweaks like giving the --force-tag --use-cvs attributes. The error messages provided were pretty clear and it took about 30 minutes to convert my entire repository and I had a total of 4000 changesets.
We work on eclipse and so I got the subclipse client setup. Now i can take on rampant refactoring projects. Happy moving files around.
1. Atomic commits.
2 CVS maintains the file level versioning whereas SVN maintains a project level versioning. We get the changeset of what files were changed in a particular commit without the hacks of same time commits as in CVS.
3 Braching and tagging are now a O(1) operation than O(n) as it was in CVS. For us we do a lot of releases and tagging and branching operations were quiet often and we used to wait for 10-15 mins for it to complete. Now it just zips fast.
4 File renaming and even directory level tracking. (This is one feature for which I would definitely change. We do a lot of refactoring and it was causing us loose history in cvs and now its like a breeze)
5 Better handling of the binary files. We maintain a lot of word doc and if some users forget the -kb switch we were really loking for a trouble in cvs.
6 Better network usage. Some of the operations like diff, revert, status can be done without the network so it makes your job easy to carry work home and work without the repository.
7 separation of update and status clears a lot of confusion and you can update the code only when you need it not to look at the changes made.
8 Properties handling is much cleaner way of storing associate information.
9. Undoing changes made in a single changeset is much easier than rolling back at each file level.
Ok I think we are convinced that SVN gives better facilities than CVS. Now coming to moving of the repository we would like to maintain the history of the repository. There are a couple of ways of doing it
1. To get the latest source code imported to SVN and maintain the CVS as a readonly repository for previous history.
2. Use cvs2svn or there are a couple of more scripts available to convert your cvs repository to SVN repository. They convert your branches, tags and group the changesets based on the time of commit. My version of CVSNT I had was 2.0.51d. I downloaded CVS2SVN 1.3 version and started my conversion.
CVS2SVN conversion program doesnt work on Windows environment. I downloaded the cygwin library and ran the python script from cygwin and boom the repository got converted. I had to do some tweaks like giving the --force-tag --use-cvs attributes. The error messages provided were pretty clear and it took about 30 minutes to convert my entire repository and I had a total of 4000 changesets.
We work on eclipse and so I got the subclipse client setup. Now i can take on rampant refactoring projects. Happy moving files around.
posted by Suresh at
1:28 PM
1 Comments:
If you're developing using windows, I highly recommend TortoiseSVN, a windows shell extension that has a lot of really nice features.
By
Anonymous, at 7:07 AM
Post a Comment
<< Home