Subversion question

Question

What is the best way to structure a repository in Subversion for Visual Studio projects?

I have a few C# .dll projects which are common to many applications. Currently, I have one big repository. I have each dll stored as a separate project within the repository and every application project stored as a project within the same repository.

I recently switched to Subversion for source control and I fear that I did not do a good job of structuring the repository. I would like to hear what others are doing.

Answer 1

Subversion repositories are typical sub-divided into:

branch/
tags/
trunk/

You would either place all of your DLL and application projects into the trunk and then use branch and tags for all of them as necessary too:

branch/
tags/
trunk/
    project1/
    project2/

Alternatively, you could create folders for each project in the root and then place the common branch, tags and trunk folders within them.

project1/
    branch/
    tags/
    trunk/

project2/
    branch/
    tags/
    trunk/

Note that this practice is simply convention and nothing in SVN requires (or really promotes) doing it exactly this way. However, everyone is used to it. So, you would be doing people a favor to go along.

To elaborate further, the trunk is where your main development will take place. When you want to mark a particular revision (e.g. a release version), then simply svn copy the project into the tags directory. Also, just copy code into the branch directory when you want to do something dramatic or prolonged and don't want to hinder progress in the trunk. Later you can svn merge your branch back into the trunk when it is ready for action!

If you want to correct mishaps in your current Subverion repository, then just use svn move to relocate them. Unlike the delete and add process of CVS, move will retain version history for the new location.

Answer 2

if your sub projects can be released at different versions (like controls, web parts, ect...) then it may make sense to build your structure like this:

Solution
Project 1

• Branch
• Tags
• Trunk

Project 2

• Branch
• Tags
• Trunk

This way you can manage each project release independently.

Otherwise the most common structure is:

• Branch
• Tags
• Trunk
• Docs (Optional)

Answer 3

using the branch/trunk/tag repository structure is pretty standard, but if I'm understanding you properly, your issue is that you have a set of common dll projects that get used across multiple projects. This can definately become tricky to manage.

So the typical scenario here is that you have some class library called Common.Helpers that has code that is common to all your applications.

Let's say I'm starting a new application called StackOverflow.Web that needs to reference Common.Helpers.

Usually what you would do is create a new solution file and add a new project called Stackoverflow.Web and add the existing Common.Helpers project and then reference it from the new Stackoverflow.Web project.

What I usually try and do is create a repository for the Common.Helpers project and then in subversion reference it as an external. That way you can keep the code under source control in a single location, but still use it seperately in multiple projects.

Answer 4

I store everything in the repository to make it easy for developers (or rebuilt devboxes) to check-out from SVN and then run a build (with all necessary assemblies in relative paths). If you have multiple projects that should be separate, this would also encourage the team of your shared components to deliver high quality assemblies. This could follow a normal release to production mentality where the shared assemblied would be updated in your downstream projects. This is a very natural Software Value Chain, at the cost of a little bit of disk space.

JP Boodhoo has a great series on the topic of automated builds, VS folder structure, and getting developers up and running quickly.

Answer 5

Thanks to everyone who answered. lomaxx, I spent the morning looking into using the external feature and it looks like this is the way to go. I was not aware of it, probably because it is not exactly prominent in Tortoise.

Answer 6

If you want to use the merge-tracking of Subversion 1.5 over more than one project at the same time you should use a single tree without externals.

A tracked merge is (just like a commit) always over a directory and its children.

The same rule applies on atomic commits. (Works only stable within a single workingcopy. It might work in some specific other cases but that behavior is not guaranteed)

Answer 7

Here's how I did it. I also was worried about how I created the repository, but it seems to be working for us.

http://stackoverflow.com/questions/16829/structure-of-projects-in-version-control#17363