Over the years I've been using source control kind off and on for my personal development. I would really love to use source control all the time but in the past I've had a number of issues in making things work correctly with the way I work on my internal projects. For work I do with customers I generally can use source control with no issues because projects are set up atomically with everything needed - all the various projects - parcelled out into a separate directory tree that's easily managed. However, for my internal work I tend to share a lot of library projects into the various top level solutions and I've never been able to get that to work reliably in Visual Studio.
Here's a little background.
Internally I've mostly been using SourceGear Vault and I've been fairly happy with it. Maybe the biggest thing that originally attracted me to Vault was that it was easy to get going and set up and work ontop of the .NET stack - it works with IIS and handles installation of server and client components for VS.NET with a minimum of fuss without having to drop to command line installs <s>. At the time the command line would have been a major frustration (ie. CVS, Subversion etc.).
The biggest issue with Vault has not been a functional but a financial issue. Pricing is reasonable for licensing (and a single individual license for 1 developer is free), but keeping up with the licensing year after year is getting expensive especially when rotating through users on a number of projects.
This weekend I also spent sometime looking at Subversion again for the first time since it was pre-release. As I'm working with another customer looking for a source solution I thought I should reevaluate and take another look at Subversion and spent the better part of the day installing and testing Subversion. It's come a long way in terms of installation pain and interoperability for Visual Studio (with the Ankh plug-in that works well).
Subversion worked very well, although the initial configuration of server and client took a bit of time to step through originally, as is to be expected when you are dealing with command line interface. Luckily there are several excellent walk-throughs out there that help you get started with setting up Subversion for operation with Visual Studio (the one that I like best is this one).
Subversion can run with its own built in distributed server interface which is small, lightweight and self contained which is great. But the built in server doesn't use HTTP and in order to run over a firewall friendly HTTP interface Apache is required. For SC connectivity on the road HTTP is pretty much a requirement and given that I run IIS on my server using Apache is not really an option (as you can't have both IIS and Apache serving port 80). So for me personally I'm going to have to re-evaluate whether Subversion is going to work out.
On a more functional level though I keep running into a problem with source control integrated with VS.NET that's been difficult to work around. This was one of the reasons I thought I'd give Subversion a shot as well, but it looks like the behavior of shared projects is somewhat similar to that of Vault (which may mean it's actually an issue with the VS.NET SCC provider). It's also quite possible that I'm simply ignorant of a feature to make this work a bit easier...
So here is the scenario that I'm dealing with. I have 4 different internal Solutions that I work on here regularily and each of these Solutions has a number of common 'framework' projects. Typically in my apps I have a UI project (ie. a Web or WinForms project), an app specific business objects project, and 3 separate projects that make up the business object framework, a utility project, and a custom UI control project. The latter 3 projects are basically attached to each of the solutions and changes made in one affect the other solutions potentially.
These reusable projects are what I call framework projects which means that they are fairly stable and any changes are carefully versioned in such a way as to not break existing code, so there's very little concern of changes in these framework projects breaking the other solutions. The process works well enough when not using source control.
In terms of physical layout of my development tree I have a base directory that most projects are stored in with subdirectories for each of the projects so for example I have:
Everything is in (I think) easily accessible relative paths so it's easy to move the code around as needed. The solutions are in the root path and they reference projects in the child paths. The project files are contained in the various project directories (except for stock ASP.NET projects which don't have a project file).
Now if I add source control into the mix, it always works just fine adding the first Solution to source control. With Vault when I add the project it will do all the work and create the source code repository subtree for me and add each of the projects as a child project. Subversion does the same sort of thing plus it flattens any directory hierarchies if the hierarchy involves distinct directory trees.
Once the single solution is under source control both Vault and Subversion work great with it.
So then once I open the second Solution (which is not under source control yet) I can see that the shared project now show up as under source control in VS.NET while the Solution itself and the main projects (ie. WebStore) are not. This is kinda nice - I get part of the way there, without doing anything <s>.
Unfortunately getting the entire Solution under source control now doesn't work with either Vault or Subversion. In Vault I get something like this:
Subversion/Ankh gets a similar although somewhat more descriptive error complaining about the Project2005 folder already being under source control. The issue is that both projects share the common root (Projects2005) in which the solution file is stored:
In Vault I can get this to work by manually adding the projects to the Solutions base subdirectory manually in the client explorer and while that works, it appears that something gets munged up between the VS.NET integration and Vault. While the Vault client sees changes I make to any source code in these manually added projects, the Vault client in VS.NET does not unless I explicitly check out the files - ie the automatic detection of changes to the source files is missing. (Correction - it looks like it is showing the updates, but it's inconsistent - apparently there's a refresh issue in VS.NET rearing its head again).
With Subversion and Ankh I'm not really sure how I can properly set up my second Solution. The first solution works just fine, but the second solution fails to load as did the Vault solution. So I use the ToroiseSVN to manually add the folders to the source code tree. The result in the Repository Browser looks like this:
which looks fine here, but looks like this in VS.NET:
IOW, it looks like Ankh/Subversion recognize that the directory is under source control, but it doesn't want to properly track it in VS.NET. Notice that the other shared libraries are showing up under source control from the first Solution that added these projects to source control. I'm not sure how to make Ankh properly recognize these files and the project at this point. <shrug>
So anyway, I'm not exactly very well versed with source control strategies so I could use some input on a couple of points:
a) Running Subversion on the Web
Anybody using Subversion internally on their servers and over the Web? Is there a way to somehow run on IIS (Web Dav maybe in some way?) What's the best solution for backing up repositories?
b) Sharing Library Projects
I'd think that the approach I've taken in setting up my shared projects in multiple solutions a fairly common scenario but I'm not really sure. Is this the best way to manage these projects this way? There are alternatives that range from setting the libraries up in a separate solution altogether to simply and simply not including the source of the framework projects in the application level solutions.
Other Posts you might also like