Question

How do I keep multiple related Visual Studio solutions/projects organized in a SVN repository (or multiple repositories)?

E.g. I have two applications (solutions) which share several common projects:

+ Application_1
  - Company.Core
  - Company.Connections
  - Company.Data
  - Company.A1.DAL
  - Company.A1.BL
  - Company.A1.UX

+ Application_2
  - Company.Core
  - Company.Connections
  - Company.Data
  - Company.A2.DAL
  - Company.A2.BL
  - Company.A2.UX

Right not, both Application_1 and Application_2 share the same SVN root, because they use common projects:

/svnroot
   /common
      /trunk
         /Company.Core
         /Company.Connections
         /Company.Data
   /app1
      /trunk
         /A1.DAL
         /A1...
   /app2
      /trunk
         /A2.DAL
         /A2...

The reason for this is that is ensures that any release has the latest available assemblies from the common folder, and that checkouts are always consistent on each machine.

So what I’d like to know is:

• Should each solution actually have its own repository?
• If yes, how do I share common projects and make sure they are up-to-date?
• Do I add common assemblies as already built dependencies (.dlls) and commit them to each solution repository separately? How do I automate such builds?

Answer 1

How you set up your repositories is completely up to you and how it works for your organization. I’ve seen several approaches for this, and over the years, found no solid advice.

Edit

That last part was written badly. What I meant by “no solid advice” is that none of the advice says “you should structure your repository as follows…” All of the advice is presented as “this is what works for us” and every one of those ways of laying out the repo DOES work for them, and the layouts vary. So I really meant “no solid advice that applies to every organization”.

end edit

However, your repository is structured very close to how our is. We have hundreds of projects, and several nodes off the root. All of these are in the same repository.

Like you, we have a common directory that holds projects with common functions that we add as reference to projects in solutions in other nodes. It’s what we came up with after many restructures in a trial-and-error process,and it’s hth one that works for us, so I’d give you a thumbs-up on your structure.

To answer your specific points

• I think you should have one repository with the structure you described coming off the trunk.
• This allows you to get your code in one checkout, ensuring everything is easy to maintain and keep up-to-date. Simply add your references since everything is in the same repo.
• Finally, our general rule of thumb is, always add your reference to a project where necessary, and do NOT check in binaries EXCEPT for where you need a common dll and you don’t have the source (such as a 3rd part component). for example, we have the Microsoft.AntiXss dll and the Idunno.Anti-Csrf dll in a “shared dlls” in our “common” folder.

As a side note, this structure also led to an easy time of setting up a build server. When we got our CruiseControl.NET build server set up, we have it do one checkout and build everything by pointing to the .sln files, just as we would in visual Studio. having it in one repo and following the guidelines I just laid out made it very easy to set up our builds.