SourceControl.VSS
Excluding vwd.webinfo from adding to VSS from VS 2005
When I have a ASP.NET WebSite (NOT WebApplication), I notice the presense of vwd.webinfo in my VS 2005 solution. The problem is the annoyance when it shows as a new source control item. (with a plus sign next to the filename). So, when ever I do a “Pending Checkins”/“Checkin”, it is included as part of the pending items.
At the moment I am taking care to uncheck this file and then do the checkin.
But, it would be nice to have tell VSS to exclude this file (or set of files) from trying to add to VSS.
I’ve also thought about “exclude from this project” option in Solution Explorer within VS 2005, but then it adds a file called vwd.webinfo.exclude and then this shows up in pending checkins once again.
Using the VSS client, there is a facility to include FileTypes. To my surprise, the *.webinfo was not included but still the VS 2005’s VSS plug-in tries to add it.
I’ve never managed to get an solution to this problem yet. Hopefully something might turn out at a later time.
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.
Finally, A Good Bye to Visual SourceSafe!
In my previous post on “Using CVS with VS.NET”, I’ve discussed the need to switch to CVS and also the problems faced in doing so.
After long time (nearly 2 months) my team has finally become very comfortable with using CVS and VS.NET. Looking back 2 months from today, I get reminded of those days when a whole day would be spent by me wondering who did what and what went wrong. With good push from my team-mate, Jimson, CVS was finally chosen as our Source Control. We did find a good plug-in called “Push-Ok” for VS.NET 2003. An excellent plug-in I should say. But, it came for a price.
We chose to stick on to Tortoise CVS and take the hard way around. We found that apart from files being edited by us, the VS.NET IDE also changed some files (like .csproj). Then with the help of Jimson, found out the right files to got into the CVS repository. Thus, after a half day session for the team on how to use “CVS with VS.NET” things got settled and now everyone seems to be comfortable with the “Copy-Modify-Merge” way of doing things.
A great feeling and a great relief….
Good going team…..