Version-controlling version-specific files

Question

Imagine an application with several released versions: V1.0, V1.1, and V1.2.

Now imagine one or more associated files that are version-specific, for example a user manual, a functional test suite, or some technical documentation. Ideally these files would be checked into version together with the application itself, so that it's easy to view and/or check out all the files relating to a specific version (e.g. to run the functional tests as part of a continuous build).

The problem is that any of these files might need to be updated even when the code is not. For example, we might discover errors in the V1.0 user manual that we want to fix for the benefit of customers still using that version. Or we might want to improve the coverage of the functional tests for V1.2 in order to discover bugs in that version before our customers do. Having changed those files accordingly, how do we commit them to version control? We're not releasing new versions of the software, just new versions of the files that go with them.

FWIW, we're using SVN.

Answer 1

I don't really see a problem.

You commit as often as you like; what you're talking about is being able bring down different revisions of the given documents, and condense them into a single "release". It's quite possible to do this, depending on how you build. You can just update specific things to specific versions (at least in SVN you can, I can't speak for other systems [say, visual source safe (god help you)]).

If it is SVN you're using, you may also be interested in the 'tagging' feature.

Answer 2

If everything relating to the project (documentation, functional tests) is copied (branched) when you release a new version, then all you have to do is update what you need to on the branch.

Typically this is done by merging from trunk, but it may not be if the change is specific to that version.