From: Martins Kemme <mkemme_at_ml.lv>
Date: 2007-01-20 21:25:06 CET
One of configuration management basic principles is keeping track of configuration item status. This answers questions - which revision is approved? which revision is deployed to production? etc. To provide this, it is very common to apply tags to various file revisions. In SVN it is done usually by copying files from trunk/ to the respective branch/* directory. Unfortunately this operation is not straightforward from logical point of view, because we create new file revision rather than apply a mark/tag (i.e. "Approved", "Released") for a particular file revision. It is inconvenient from practical aspect as well if every file version copy has a different revision number. As a workaround for this technical issue we could create "Approved" or "Released" branches in our repository, but this approach has some drawbacks.
Let's examine the following example - we need to track when a file revision is deployed in production environment. In case we want to deploy all files in particular revision, then we could create a copy whole trunk/ revision to a new tag directory. Therefore we would create a set of tags (say "in-production_on_Jan10", "in-production_on_Feb10") every time we deploy to production. But what if we want to deploy a mixed revision file set to production? We can't use svn copy functionality because then we would need to pick by hand particular revisions of thousands of files (trunk is big!). To workaround this we should create "branches/in-production" directory and merge in there all mixed revisions of files that are promoted to production. That would be an acceptable solution, if only ... this would not create new revisions for all merged files. And here is the problem.
If we are depicting revision number in file contents as well (using keyword Revision), then after marking that this file is released, the in-production version of a file contains different revision number than in trunk (development). And if we would like to compare production revisions with these in development trunk/ it comes down to comparing file contents again as we can't rely on embedded revision numbers.
So the question is - are there any plans to implement improvements in tagging concept? More flexible solution would be an option to attach tag/property to a particular file revision.
This is an archived mail posted to the Subversion Users mailing list.