具有不同svn存储库的不同项目中的代码管理

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, ie:

/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.

Answer 3

My advise will be to put in the same repository projects with the same lifecycle.

Let's take your A scenario. We have:

1. Shared Class Library project (which is for lots of different solutions)
2. Another Class Library project (which is only for this solution)
3. Web Application project (which main part of this solution)
4. Shared Web Service project (which also serves for different solutions)

That'll make one repository for 2 & 3 which are different projects of the same solution (hence with the same life cycle):

/solution-A/trunk/ClassLib
/solution-A/trunk/WebApp
/solution-A/tags/1.0.0/ClassLib
/solution-A/tags/1.0.0/WebApp

And one repository for 1 & another for 4 assuming that they have different life cycles.

/library-A/trunk/ShClassLib
/library-A/tags/1.0.0/ShClassLib
/library-B/trunk/ShWebService
/library-B/tags/1.0.0/ShWebService

Now depending on the subject on which a developer is working he can check out either the trunk, a tag (read only) or a branch. For instance a developer working on the solution using released libraries will check out the trunk of the solution and the right tags for the libraries. The same one requiring the next versions of the libraries will check out the trunk (or a branch) for the libraries, etc.

Of course it'll be probably better to have a build/release system able to deliver binary releases for the libraries as well as nightly builds.

Answer 4

There's really not much to say about Visual Studio support because using Subversion and Tortoise don't work inside of Visual Studio. When you're dealing with projects and solutions you might want to carefully consider whether project and solution settings affect other users. If your local paths are not the same as the projects in the repository for example, you may have to check out the project and solution files and leave them checked out permanently.

For Web applications often the web.config file might require some careful consideration if there are machine specific settings in the file. For example, if you're running IIS 7 and you download a project that's was created with IIS 6 the project file will be changed potentially to point at system module and handler references in different locations. Or you may have a connection string pointing to a different server than the original web.config file. Here too the solution is to download the file originally and then keep the file checked out locally and remember not to update it.

My sincere suggestion is to put the projects into same repository; it's easy to find and backup. But the key thing to remember when creating new branches and adding new files in the repository is:

Create Folder in Repository first

Checkout just the Folder to your local folder

Add Files with Tortoise in Explorer

Commit changes

Side note:

If you prefer to have Visual Studio integration for source control you can check out VisualSvn which provides integration with TortoiseSVN directly from within Visual Studio. Visual SVN works with your existing Subversion folders so it doesn't use Visual Studio version control provider (a good thing IMHO). Rather it talks to the TortoiseSVN APIs and gets its data directly from the file store. I haven't used Visual SVN for long but so far it looks nice, although I've gotten so used to using Explorer for source control it doesn't help significantly to have the integration.

One thing that's definitely easier is creation of new projects – you can just use Add to Subversion and VSVN will take care of creating the branch and checking out the files for you.

It's definitely nice to see the status of files right in the IDE and it's also nice if you frequently add new files to the system as VSVN knows about Visual Studio file associations and automatically adds all related files.