Subversion

As I mentioned last Monday, I have been working with PC Pitstop on a regular basis again since last summer. Way back in 1999, Dave Methvin and I set up the PC Pitstop development effort as a completely virtual company: we had managed servers, but everyone worked from their own digs. We used Microsoft Visual Studio 6.0 for most of our development: Visual InterDev 6.0 as our Web application IDE, Visual C++ 6.0 as our C++ IDE, and Visual SourceSafe (VSS) as our version control solution.

When I took over the ActiveX control development again last summer, I basically unpacked Dave’s current project archive, put it under version control with VSS in Visual Studio 2003, and continued from there. Dave had a Subversion (SVN) server installed that he used for a few projects, but I was used to checking files in and out of VSS from within Visual Studio, so I stuck with what I knew. Call it the natural conservatism of programmers.

The trouble was that I’d still have to send archives around with my changed files. Email is not really the ideal version control and file sharing system. Posting archives to an intranet file share is only slightly better than mailing them.

Finally, last week, I installed the TortoiseSVN client for Subversion on the computer that has Visual Studio 2003. To create my projects in Subversion, I used the TortoiseSVN repository browser to create a folder for each C++ project, plus trunk, branches, and tags subfolders. Then I unpacked the source code archive for each project into a temporary directory and imported those directories into the appropriate trunk folders in the Subversion repository.

When Dave tried checking out a project and opening it in Visual Studio, he got an error message:

The solution appears to be under source control, but its binding information cannot be found. It is possible that the MSSCCPRJ.SCC file or another item that holds the source control settings for the solution, has been deleted. Because it is not possible to recover this missing information automatically, the projects whose bindings are missing will be treated as not under source control.

Unfortunately, he got the same message again each time he reopened the project. When I added the MSSCCPRJ.SCC file to the Subversion archive, he was able to get a dialog about the binding being to a non-existent store, from which he could cancel and use the project. Dave also figured out that he could remove these four lines from the .vcproj file to remove the source control binding:

 SccProjectName="SAK"  SccAuxPath="SAK"  SccLocalPath="SAK"  SccProvider="SAK" When I tried to check out the folder from Subversion on top of my VSS-controlled project, I got a warning message from TortoiseSVN about a non-empty directory; when I tried to accept that and proceed, I got error messages about the files already existing, which I couldn’t get past. I had to check out to an empty directory to create the TortoiseSVN bindings.

That being the case, I decided to go with a two-local-directory solution. I took MSSCCPRJ.SCC out of the Subversion repository, and removed the four lines shown above from the .vcproj file. After committing my changes, the SVN version of the project loaded into Visual Studio without VSS bindings, and the original project continued to load into Visual Studio with VSS.

Now I’m using the original project with VSS as a local sandbox. When I come to the logical end of a series of changes and the project both builds and tests successfully, I copy the changed files into my local SVN project directory and commit them to the server.

This works for me, although I don’t think it’s ideal. Does anyone have a better solution?