Perforce, Visual Studio and branching.

Question

We are in the process of trying to implement perforce in our small IT department. We're primarily developing in .net using visual studio 2008. I've organized my projects as follows:

Customer
    Product
        main_line
        version_1
        version_2
Libraries
    Library_Name
        main_line
        version_1

A main_line/version folders contain the solution file as well as the code files for the main project in the solution. The solution typically includes one or more projects contained in the "Libraries" hierarchy, and those library projects are usually included in multiple solutions. In perforce this seems to work fine as long as I apply source control to individual projects as opposed to entire solutions. In fact, either the perforce plug-in, or visual studio itself, gives me a warning if I try to source control solutions that share common projects/libraries.

The problems start happening when I try to branch solutions. Since I'm not source controlling the entire solution, the .sln file is not copied to the branch directory, which I suspect is would be useless anyway due to incorrect file mappings. My question is, am I doing something wrong or is branching of visual studio solutions always this painful? Is there a better way? Perforce seems work well only for simple solutions. Is there a source control product that works better with visual studio?

Answer 1

I think that Perforce is the lesser part of the problem. You don't mention what specific problems you're seeing when you try to share common projects/libraries, and neither how you try to do it.

I assume that you want to use stable library versions for each product version? I'd recommend you to branch the library at the correct version to a location under the product's depot path. Depending on the nature of your project you could then also build the library inside the product workspace and check in the artifacts (e.g. dlls) for easy and reproducible builds. Example:

//depot
    /customer
        /product
            /MAIN
                /deps
                    /src
                        /lib1 ... (branched from lib1/REL1 below)
                    /bin
                        /lib1 ... (prebuilt libs)
//depot
    /libs
        /lib1
            /MAIN
            /REL1

Treat the "//depot/customer/product/MAIN/deps/src/lib1/..." path as read-only. Doing this by convention is the easiest way, but you could customize the protection mapping in Perforce to enforce this. Don't do it unless you are really sure you need it, though, as you'll be adding complexity.

Once you've done this you can easily add the solution file for the whole product to Perforce. (The solution does not need to reference the library "directly" as you won't be working on it in the context of the product.)

Depending on the nature and composition of your product you'll probably instead want to use "subsolutions" for different parts of the product (exes, libs, installers) to make it somewhat easier to work concurrently on different parts of the product. Perforce has excellent merging capabilities, but I prefer to try and avoid merging solution/project files.

When you then would like to release a new version of "product", branch everything under MAIN to e.g. REL1 (including the dependencies part). If the new product version needs an updated version of the lib you could just "p4 delete" the applicable stuff under the product depot path and branch/integrate the correct version as described above.

NOTE: It should be possible to just perform an integration from the new version of the lib into the e.g. deps/libs/src/lib1/ location of the product, as they have common ancestors. I'm not 100% sure about this though, so I would recommend starting out with the p4 delete/integrate new approach.

NOTE2: Paths inside the solution and project files are generally relative to the solution/project file itself, so branching should work just fine in this respect. Just don't add references to other files/directories using absolute paths yourself.

Answer 2

I managed to get this worked out pretty well. What seemed to cause a problem for me was having my solution file (.sln) in the same directory as the code for my start-up/main project. I moved the project code to it's own sub-folder at one level below the actual solution.

Customer
    Product
        main_line
           sln_file
           src
              code
    Library_Name
        main_line
           src

This allowed me to make all of the project references in the sln_file relative. Then I add the code in the src folder to the depot via the visual studio plug-in. I add the projects individually, not the entire solution. The only issue is that I have to manage the sln file through p4v directly, but since it doesn't change all that often anyway, this isn't really a problem. Now, when I branch main_line, I get a copy of the .sln file, with relative references, and everything works as expected.