Best strategy for branching SVN code and maintaining Visual Studio project references

Question

We have a main visual studio project stored in SVN using the standard trunk/branches/tags structure. However, this project references external projects outside of this structure, so when we create a code branch all the references to the exteranl projects fail as they are one level out.

ie. trunk/MyProjectCode becomes branches/MyFeatureBranch/MyProjectCode after branching, and so due to this extra level of hierarchy any references to external projects fail.

What is the best approach to creating branches with as little friction as possible? I could write a script that modifies all the project references, or I could could change my local code layout so branches were actually a level down from trunk, so therefore a new branch would be on the same level. Any other suggestions/best practices?

Answer 1

We branch everything which pertains to that product. So if there are 5 projects which are part of it, we branch all 5 projects, to make sure that the we have a complete copy of what that branch is going to use. If you are having problems with paths, you might want to check out a program called Junction.

Answer 2

When checking out from Subversion, your working directory doesn't have to reflect the same directory depth as in the repository. Using the command line for example purposes:

svn co svn://server/project/trunk project
svn co svn://server/project/branches/MyFeatureBranch project-feature

That way, you'll have two directories side by side called project and project-feature. This should avoid problems with differing directory depths and relative path references.

Answer 3

What I have done in the past is, for a development shop developing many projects and lots of common references, was to keep the external references in a shared location. This may be a network share, or an agreed (absolute) location that everyone has on their hard drive (structured like C:\SharedLibs\Library\Version). We kept the sharedlibs in a seperate svn repository which everyone had to check out to that SharedLibs folder, and set up our references to this absolute path.

Another strategy I've applied is what you also find in lots of open-source projects: just store the references alongside your project. E.g. you could have a trunk with subfolders src (for source code) and lib (for external references). This is probably better practice: all you need to do to build the project (be it trunk or branch) is check it out and run your build tool.

Yet another option is using the svn:externals property. With this property, you can make sure that files from other locations in your repository (or from other repositories) are checked out together with your project. From experience, I don't recommend this but it is an option. Read about it in the svn book: http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html

Answer 4

We had the same problem here and I've thought about editting the .sln and .csproj files replace the relative paths with absolute ones. I was a little concerned about doing this as VS maintains these files and what is to stop it from undoing this and reverting back to relative paths at some point in the future (when a Dev saves the project and checks it in for instance).

This morning I had a 'moment of clarity' on my commute: Even though we are storing the branch in a dedicated branches folder, why do I have to check it out into one?

so, instead of:

C:
 |_ svnworkarea
       |_ project
           |_ branches
               |_ project-feature
                       |_ source etc

           |_ trunk
               |_ source etc

I now have:

C:
 |_ svnworkarea
    |_ project
         |_ project-feature
               |_ source etc

         |_ trunk
               |_ source etc

As the source folders are now at the same level the relative paths are valid and the references load as expected. The trunk is still totally separate an easily identifyable while the project-features are identified by a meaningful folder name, e.g. NewUIBranch.