SourceControl.CVS
From VSS to CVS; From CVS to SVN
Hmm…..After VSS came CVS and now after CVS it’s time to try out SVN!
Yesterday, I was finally determined to make my machine a build system(with WinXP SP2 Pro) for which I had to install and configure CruiseControl.NET. For which I had to install VSS. Then I thought of CVS (because, I was comfortable with CVS way of doing things for the past 1 year). Oh…then I thought of SVN (because, SVN is to be a compelling replacement for CVS).
The best part of SVN is the availability of the free e-book which is quite exhaustive. I was indeed more happy to read the TortoiseSVN e-book because it gave detailed steps to install the SVN Server and not just the TortoiseSVN Client.
Since I did not have Apache Web Server in my system, I prefered the SVNServe type of SVN Server which listens on port 3690. With that I had my svn server setup but before running the server, I read a piece of information in the book which said that the svnserve.exe can be run as a windows service using a wrapper called SVNService. Without much thought, I tried running the svnserve as windows service.
But, to my despair when I tried to view the repository which I had just created using TortoiseSVN, I could not find the repository using the repo-browser of TortoiseSVN. Something has gone wrong somewhere….After 30 minutes, I started to suspect the SVNService wrapper. So, instead of going to that level of abstraction, I decided to run the svnserve manually using command prompt. And lo there was Windows XP SP2 in action asking my permission to unblock the port 3690. Phew! that was a relief. After unblocking it, I reverted back to SVNService.
There ended my initial adventure with SVN which was quite less exciting than my earlier ones with CVS and TortoiseCVS. I am expecting the real thrill when I start using ASP.NET application with SVN.
Using CVS for SourceControl
“An alternative to VSS” was the requirement. Decided to plunge into CVS. SA had the CVS server installed on a Linux machine. My task was to find and explore the various CVS clients for Windows.
First, tried WinCVS. Then went on to look for CVS plugins for VS.NET. Found Jalindi Igloo. Igloo was a major failure inspite of a detailed article on the CodeProject.
Then looked into the TortoiseCVS. Inspiring integration with the windows shell. The ease of use was spell bounding. The help accompanying installation gave a detailed look into the two different methodologies for SourceControl namely, Lock-Modify-Unlock and Copy-Modify-Merge. TortoiseCVS uses C-M-M model.
A VS.NET plugin for TortoiseCVS was under development. I tried it but failed to Check out a module.
Then looked into the SubVersion alternative for CVS. Even this follows C-M-M model. But, the VS.NET plugin developed for SubVersion, ankhsvn looks good by seing the Screen Shots. Got to install svn soon and try it. The free book on subversion is excellent.
Then went on to read the Microsoft’s “Team Development Guide” from Patterns&Practices. This guide is indispensible for VSS and VS.NET users.
Another Microsoft Article from MSDN was very good. This is related to SourceControl and build control for Web Projects.
For now, using WinCVS and TortoiseCVS together.
Waiting for something to happen………