Hear Hear.
After watching posts like this fly by over and over on the mailing lists
I thought I'd add my vote for such a feature as well.
We switched from CVS to Subversion several months ago and this has
indeed been the single most confusing thing to my developers. We are a
web development shop and it is not uncommon for three or four separate
releases to our production site per day. Creating new branches for all
of these is not feasible, especially not for the graphics designers
submitting images. I set up a series of scripts to allow automatic
merging of revisions using the svnmerge scripts, but this has proven to
be brittle and breaks easily on conflicts.
Very often my developers say 'I just want revision x to go to release'
Thanks,
Leon
________________________________
From: Martins Kemme [mailto:mkemme@ml.lv]
Sent: Saturday, January 20, 2007 2:25 PM
To: users@subversion.tigris.org
Subject: Subversion tagging
Hi!
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.
Or, in case someone has good experience on how to track logical
status of all changes, please share your experience.
Martins
Received on Mon Jan 22 17:34:28 2007