Question

Scenario

I have a Library that contains Projects A, B, and C.

I have two solutions. Solution 1 includes a copy of Project A, and Solution 2 includes a copy of Projects A and B.

---

When I build Solution 1, here’s what should happen:

---

When I build Solution 2, here’s what should happen:

---

How can I do this?

Is this something I could automate with a version control system or off-the-shelf file syncing software? Or do I need to roll my own solution?

If I do build my own solution, I have some thoughts on how it could work, but I’d appreciate any input you may have:

• Could be a simple console app with a command-line switch for specifying the “source solution”, for example:

  c:\Program Files\Library Syncronizer\LibSync.exe /solution:Solution 1
  

• XML file used to register active solutions that contain library projects. Possible format:

  <solutions>
    <solution>
      <name>Solution1</name>
      <path>c:\...\Projects\Solution 1</path>
    </solution>
    <solution>
      <name>Solution2</name>
      <path>c:\...\Projects\Solution 2</path>
    </solution>
    <!-- more solutions -->
  </solutions>
  

• Program would do the following:

  • Read in source solution
  • Determine what library projects it has
  • Copy the folders for those projects to the library
  • Loop through each solution in the XML file (except the source)
  • Copy the folders for all library projects as necessary
  • Perhaps some backup operation could also occur, just in case the syncing process overwrites something important.

This sounds relatively simple in concept, but this may have serious unintended consequences I’m not thinking of. Hopefully someone will warn me if it does 🙂

---

Update – What is my motivation for copying project folders?

In a word – Version Control.

If I keep the library projects in a separate folder and only link to them in my various solutions (rather than physically locate the folders in my solution folders), my version control repository ends up not containing the source code to my library projects. So, if I update to “three version ago”, and I need to make a minor change to one of my library methods, the code is not there.

My workaround for this has been to add tags to the revisions in my library’s repository that say things like “Solution 1 – Version 2.5.3”, but this is pretty clunky. And things get really awkward if I’m working on “three version ago of” of Solution 1 and the current version of Solution 2. Now, Solution 2 will be pointing to an old version of the library projects, which makes it potentially impossible to work with and test until I’m done working on the old version of Solution 1.

If I were working with copies instead, all solutions would contain the library source code in their repositories, and I could go back to it easily any time I need to.

I should note here that I’ve been using Tortoise HG (Mercurial) for version control.

Anyway, I’m open to any solution to this problem. It doesn’t have to involve copying project folders around–that’s just the only thing I could think of to ensure that all my version control repositories are complete, stand-alone packages.

---

Update 2

First of all, just a note. I’m using Mercurial (TortoiseHG) for version control, not SVN. I could change if absolutely necessary, but I really prefer Mercurial.

Based on responses so far, I’ve decided to do away with the “bi-directional copying” idea, and go back to referencing my library projects. Here’s a new diagram:

I continue to have the same goals, however:

1. Latest version of each solution is using latest library code
2. One solution/application per repository
3. Each repository contains all source code, including library projects
4. Everything is as automated as possible to minimize the risk of mistakes

Goal #1 is taken care of automatically by referencing the library projects instead of using copies, and Goal #2 is just a matter of how my set up my repositories, but Goals #3 and #4 remain elusive.

With Mercurial, there is a subrepositories feature that seems like it would handle my situation, but as the documentation indicates, this is still considered experimental/risky.

For the moment, I’m thinking a good workaround might be to just store backup copies of the library projects in my Solution folders. When I say “backup copies”, I mean that literally. I would still be referencing the library projects–the copies would be solely for the purpose of ensuring all source code ends up in my repository (Goal #3). To satisfy Goal #4, these backups could be automated using a post-build event in studio.

I welcome your thoughts on any of this.

Answer 1

This sounds exactly like what the sub repository support in mercurial is for. If project A and project B, etc. are are separate repositories you can can make them sub-repos within Solutions 1 and 2. The .hgsub files in 1 and 2 are versioned themselves and point to specific revisions within A, B, and C, so you can always build with the same version in each Solution, but need not keep them in lock-step. Moving changes back from the solutions to the libraries becomes easy, and if desired, branchable.

Don’t let the “beta in 1.3” mention on that wiki page fool you. Mercurial is up to 1.4.2 now and subrepos are staying as they are.