how to handle solutions/versioning in subversion

We are using ankhsvn to check in our .net code, however I have two issues with our setup that I want to resolve.

1\ I thought a key reason to have a tool like svn is that you can rollback to an earlier version of your codebase. If developers are just checking in code, then how can you get version 1.1 (say the current production build), out of subversion?

2\ In VS you have the concept of solutions, many solutions might use the same project. How do I make sure when a developer checks out a solution, they get the 开发者_运维知识库appropriate versions of the projects that belong to that solution?

1. You need to learn about tags. The idea would be that when you reach a point that it's time for release X, you'll create a read-only /tag/release_X in your Subversion repository. You continue to work on /trunk or a /branch; if you need /tag/release_X, you simply check it out.
2. I don't know what concept of "solutions" is. If you mean you have a shared project that turns into a JAR or WAR or DLL or assembly that several projects use, you can check in the artifact and have other projects simply check it out like any other 3rd party JAR.

I'd recommend reading the SVN Red Bean book.

To create a "Tag" (new version of the application) in ankhsvn:

1. In the Solution Explorer, right-click an item and select Subversion > Branch Solution. Revert an item to a specific revision
2. In the Create Branch/Tag window, select the source for your branch or tag.
   • HEAD or latest revision in the repository
   • A specific older revision in the repository
   • Your local working copy

3. To automatically switch your working copy to the new branch, select Switch to Branch after creation.

   Note: If your working copy has modifications, those changes will be merged into the working copy of the branch when you switch.

4. Enter a log message explaining why you're creating the branch or tag.
5. Click OK.

This is a pretty crappy solution, far too manual for my taste (it does not "know" the original projects location, I don't want the process to be that onerous) what I really want is one button click to do this job, so will keep investigating.

For issue 2:

You can use the svn:externals property to associate the appropriate version of a project to a solution, if the project code is stored in different directories within the svn repository than the solutions. If you set the externals property on the solution's trunk to point to a tag, the version of the project that has been tagged will be checked out with the solution.

I don't know if the AnkhSVN interface provides a way to add the externals property as I typically use the TortoiseSVN repository browser for the task.

I will second the recommendation to read the Red Bean book.