Code management in different projects with different svn repositories

Question

First of all I want to tell you what kind of system I have and I want to build on.

1- A Solution (has)
   a- Shared Class Library project (which is for lots of different solutions)
   b- Another Class Library project (which is only for this solution)
   c- Web Application project (which main part of this solution)
   d- Shared Web Service project (which also serves for different solutions)

2- B Solution (has)
   a- Shared Class Library project (which is for lots of different solutions)
   c- Windows Form Application project (which is main part of this solution)
   d- Web Service project (which also serves for different solutions)

and other projects like that....

I am using xp-dev.com as our svn repository server. And I opened different projects for these items (Shared Class Library, Web Service project, Windows Form Application project, Web Application project, Another Class Library project) .

I want to do the versioning of all these projects of course.

My first question is, should I put each project(one solution) to one svn repository to get their revision number later on?

Or should I put each of them to different svn repository and keep( write down) their correct version number that is used to publish/deploy every solution?

If I use one svn for each project(Shared Class Lib, Web App, Shared Web Service....) how can I relate the right svn address and version on VS.2010 within the real solution?

So, how do you manage your repositories and projects?

Answer 1

I believe the correct solution to this is tagging. I don't believe it's a good idea to separate your solution across different repositories. It's advisable to keep all projects that are even slightly related in the same repository, and use a standard repository layout, i.e.:

/branches
/tags
/trunk

With all your working solution folders described above in /trunk. Trunk can contain as many projects/solutions as you feel is manageable, and could even be further organized by project type. One of my trunk folders is /trunk/websites and I keep all my website solutions in there.

When you are ready for a release version, you can "tag" your trunk, or part of your trunk, with that release or build version, using "Branch/Tag" over to /tags/ This affords you an opportunity to also record your release notes in the tagged copy.

For more information on branching and tagging in SVN (assuming Tortoise) see Branching / Tagging in the TortiseSVN docs.

For more info on these terms, see this question in StackOverflow.

I hope this is helpful. I do not know what limitations, you may be faced with from your SVN host. These suggestions are based on my experiance in hosting my own VisualSVN Server repository.

I came to SVN from SourceSafe, and it took me some time to see the value in this standard, and to begin using these practices. They are invaluable to me now.

Answer 2

Another approach you can take to this is using the Subversion externals property to be able to manage your code, either in separate repositories or in a single repository. The advantage is that you can simply update the URLs in question when you need a new release of the shared code in your solution.

Note: I don't remember jack about the Visual Studio solution and project organization; it's been at least 5 years since I've done any Windows development. That being said, this discussion is applicable no matter what the file/directory layout is. I'm going to make one up and please just adjust it to your actual situation.

Lets assume you have one big repository that has all your related projects in it. If you think that isn't necessarily scalable, I'd suggest taking a look at the Apache projects SVN setup; they have all the projects in one repository. Taking a page from the ASF, let's start out the repository structure as follows:

/SolutionA/trunk
/SolutionA/tags
/SolutionA/branches

/SolutionB/trunk
/SolutionB/tags
/SolutionB/branches

/SharedClassLib/trunk
/SharedClassLib/tags
/SharedClassLib/branches

/SharedWebService/trunk
/SharedWebService/tags
/SharedWebService/branches

So far this is just a standard SVN layout; each more-or-less independent entity has its own area of the repository to play with. Now, lets assume you've been developing away on the SharedClassLib and you are up to version 2.0.0, and on the SharedWebService you are on version 1.2.5. The directory layout will look something like:

/SharedClassLib/tags/1.0.0
/SharedClassLib/tags/1.5.0
/SharedClassLib/tags/2.0.0

/SharedWebService/tags/1.0.0
/SharedWebService/tags/1.2.0
/SharedWebService/tags/1.2.5

The other tags are just for illustration of the fact that your development has been marching on over time and you've had multiple releases.

Now, back in SolutionA, you have a LocalClassLibrary project and a LocalWebApp project. These projects are strictly part of this solution are are not shared outside of this solution. Taking a stab at a directory layout, your trunk might look something like:

/SolutionA/trunk/SolutionA/<some_solution_level_files>
/SolutionA/trunk/SolutionA/LocalClassLibrary/<some_project_level_files>
/SolutionA/trunk/SolutionA/LocalWebApp/<some_project_level_files>

So, our problem is, how do we get the SharedClassLib and SharedWebService into our SolutionA? By using Subversion externals. Read the externals web page first, then come back here.

To make your life a little easier, I'd suggest creating a svn.externals file in your solution directory to set the svn:externals property if you are doing this from the command line. If you are using some other tool, just keep in mind that in this case, you are going to need to add multiple lines. The file will look like:

SharedClassLib         http://your.svn.server/SharedClassLib/tags/2.0.0
SharedWebService       http://your.svn.server/SharedWebService/tags/1.2.5

Edit 1: At this point, you can see that the URLs you are referring to are fully qualified. Meaning that they can be separate repositories, and you don't have to use the layout I've described here. Additionally, if you are at an intermediate stage in your development and you need the latest, bleeding edge, development version of your shared code, use an URL like http://your.svn.server/SharedClassLib/trunk. At some point, however, you are going to want to settle on a sable version of the external code before you tag and release your solution.

Edit 2: Note that this is the pre-1.5 svn syntax. It has changed a bit in 1.5

Do an svn propset svn:externals -F svn.externals . in your solution directory, then svn commit && svn update. At this point svn will populate your working copy with the contents of those URLS. Your working copy would look something like:

./SolutionA/svn.externals
./SolutionA/<some_solution_level_files>
./SolutionA/LocalClassLibrary/<some_project_level_files>
./SolutionA/LocalWebApp/<some_project_level_files>
./SolutionA/SharedClassLibrary/<some_project_level_files>
./SolutionA/SharedWebApp/<some_project_level_files>

When you need to bring in new versions of the shared projects, update the svn:externals property appropriately. Please note, there are some caveats to this approach, and are detailed in the SVN externals documentation. Mainly, don't plan on being able to make changes in ./SolutionA/SharedClassLibrary and expect the changes to be magically picked up when you do a commit in SolutionA.

Now you are ready to release SolutionA to the world. Just create the appropriate tag (svn copy) of the trunk to the tags directory:

/SolutionA/tags/1.0.0

Now your SolutionA will have it's own code at the correct tag/version, and you are using the right version of the shared projects for that release.

Obviously, the same discussion applies to SolutionB.

I haven't worked with SVN in a while, so my apologies if I've gotten any of the above a little bit wrong.