Create a "label" in subversion indicating what files should be in the next release

Question

I've been using StarTeam for version control for some time, but am moving to Subversion. I've been reading the Subversion book and there seems to one major feature that StarTeam has that Subversion doesn't - the concept of labels. I know Subversion has labels, but they mean something different in StarTeam. In StarTeam, I can label a set of files as "ready to build" and then only check those out and include in a particular release. I can then create a frozen label indicating what files were included in that release (similar to a Subversion tag, except it's on those specific revisions, not everything in the directory).

Is there a way to get such functionality in Subversion? I know you can specify which revision to tag, but what happens in the situation where you have code and are about to do a release, and find a bug, or someone decides a particular change shouldn't be included. I know you can create the tag based on the repository and your local working copy, but this involves checking out specific revisions of the files that shouldn't be included and creating the tag. With a ready to build "label", you wouldn't put that label on the head version of the files you didn't want. There doesn't appear any automatic way to designate certain revisions for a build in Subversion. This isn't the case where a new feature should be developed in a branch, but more if a revision is in the trunk (or wherever you will make the tag from), but shouldn't be included. It may not need to be reverted - the change could be appropriate, but in a future release, not this current one. If you don't have a specific revision with the exact file versions you need, it seems like you'll have to manually mix and match from the repository and your working copy.

In a similar situation, what if you have files in Subversion that aren't part of the release and don't need to be tagged. In StarTeam, you wouldn't attach the ready to build label to them, but in Subversion, it seems everything in the directory. Is there a way to exclude such files from the build and tag? Is this what svndumpfilter exclude is for?

In short, is there a way to only include specific revisions of certain files in a tag, or does it have to be either a specific revision in the repository, or a manual mix of files in the repository and your working copy?

Answer 1

You branch or tag on a specific revision. You can modify a branch to have it include the specific changes or updates you want in that branch. Once you branch, you can change any number of files that you wish and update them for only that branch. So yes, individually you can update your files to an older revision, and then commit them to the branch.

Answer 2

If I understand your problem correctly, I believe it can be handled by branching at some point prior to the release (e.g. at the point all of the main functionality you want included in this release has been completed) and then carefully managing what gets merged onto that "release" branch. The "main trunk" is free for new stuff. For example, if a bug is identified then this could be (a) fixed on the main trunk and then a decision is made about whether it should also be merged into the release branch; or (b) fixed on the branch. This is the process we follow and it works quite well (but it does also require discipline and a certain amount of formal processes).

Answer 3

Subversion only allows atomically tag an entire revision of the source tree. The functionality you are looking for requires some communications between your source control and a ticketing system that maintains not only the changes to be made, but also the files that were changed for each ticket

Trac, for example, parses the commit logs for each revision to be associated to any number of tickets using the syntax # in the commit log.

You would need a module that maintains the tickets associated with the new release and then calculates which files to make part of the delta release package.

Answer 4

I think your best bet will be to use branches. Depending on how you are working on a new release, you can either create a clean branch that isn't used for active development, or keep the trunk clean and use branches for active development. Then, when you have files that are finished and ready for the next build, you merge those file changes only into the clean branch.

Let's say for example we are working in the trunk, and release version 1.0. Then we create a branch called maint-1.0 which nobody touches. We continue developing in the trunk, and as we finish certain features or functionality, we move those changed files into the maint-1.0 branch. Note that you may have to have two working copies and simply copy the changed files over. Doing an actual merge will want to merge all changes, not just specific files.

The end result is that your maint-1.0 branch only has the changes you want in your next build.

Answer 5

I think the other answers are pretty much there, but just to make it explicit, this situation is handled very well with a release branch.

The idea is to take a branch from trunk early on in development (or from an early revision - the assumption is that you want everything up to the revision you branch from), and use the normal merge mechanism to promote revisions from trunk to release. If a revision (or set of revisions) is later decided to be of bad quality, you can revert those merges. Your merge tracking (in tortoise this works really well) shows you what's included and what's still to go, and you can skip revisions, merge them out of order, and generally mess around as much as you need to get your build working. Obviously - skipping and merging out of order may well create more work for you as you will need to manually resolve the conflicts - but it's a tool that's available as you need it.

This has advantages over working with individual files as entire feature sets are promoted/removed as needed - you don't have to manually hunt around different files removing changes from here and there. But this does require that you have sane commits and comments - don't let your developers commit with "Committing for friday afternoon so everything's safe".