OK, so I am implementing an SVN repository to track development on a Dot Net project. I have defined the repository directory in accordance with the following structure:
\project
\trunk
\branches
\systest
\production
\tags
\production_yyyymmdd
Main development is committed to the trunk of the project, and development is performed based on Change Requests (CRs) from the client. For the moment, I am happy to exclude the problem of overlapping CRs (ie a file that is changed by more than on CR). My problem is how to manage the process of migrating only the file changes associated with a single CR from trunk to systest and from systest to production. The promotion process as I have it at the moment is (take migrating from systest to prod as an example):
The problem I have is with step 3. How do I tell SVN which files to merge to the Migration location. I do not want to merge all changes from systest to prod (and I might not even want to merge all changes in a particular revision from systest to prod), only changes in specific files.
Edit: I should also clarify that all the repository access is being done from a Windows client. I'm not running commands on the SVN server. (For interest's sake, the SVN server is running on Linux, but that makes no difference to the problem space I believe)
Cheers
Richard
Wow, this actually sounds like a nice sane promotion system you've got here :)
In terms of tracking things, the simplest answer I have is to enforce a certain developer discipline - that is, only include 1 CR per commit.
Tortoise has support for the bugtraq properties which can help you here by ensuring that every commit comment includes at least one CR number - it may be a useful hint to tell developers that if they're including >1 tracking number for the commit then they're probably doing it wrong (unless one fix really does do multiple things).
So this will let you merge from trunk to systemtest just with the CR's you want. You can even use the tortoise merge ui to see what revisions in trunk haven't been merged into systemtest yet. But of course now you're going to want to go from systemstest to production with similar granularity - which is what the question is about.
The problem as I see it is that a single revision in systemtest can consist of multiple trunk commits, and you may not want them all in to production just yet.
I wonder if it might not be best to do the merge into production from trunk - instead of coming from systemtest. In theory it should be the same code - you'll be able to track what trunk revisions are in system test and what's in production.
So to be clear with that, you promote a revision from trunk to systemtest, test it, then if it's ok, promote the revision from trunk to production (you may have to start a clean production branch again).
You should be able to write some tools that use mergeinfo to confirm for you which revisions are in systemtest but which aren't in production. And using the bugtraq properties, you should also be able to tell which CR's are completely merged into either branch, and which have revisions still to go.
If you're going to want to start promoting less than a complete trunk commit into test and production, you're in a bit of trouble, especially if picking changes from the same file. You could right click on indiviudal files and merge in directly on the file level (and perhaps manually undo certain changes) but choosing the files and changes will be very manual work and you won't get any help from the tools. Also, you're tracking scripts start to get extremely comples.
Be warned however, that by doing this there's a very real risk of code drift between system test and production. I'd recommend regularly doing a diff between the branches and ensuring that you can account for all the differences. If the two branches have the same revisions merged from trunk, they should be identical, any differences should be because of revisions in test that aren't yet in production, and of course, there should never be a revision in production that isn't in test.