I guess I just can't believe it. Do people switch software tools with NO
idea of how the tool works?
This is like having a motorcycle that gets 60 MPG and then switching to
a race car... then
complaining that the race car only gets 2 MPG. If mileage was important,
why did you switch?
If CVS style tags are important, why did you switch to Subversion?
The way subversion does "tagging" is, by design, NOT the same as CVS. I
happen to
favor the way Subversion does it, and look forward to using Subversion.
I'm re-designing
our current Version Control System to take advantage of how Subversion
works, rather than
worrying about the lack of CVS style tags...
-----Original Message-----
From: Leon Oosterwijk [mailto:leono@daveramsey.com]
Sent: Monday, January 22, 2007 10:34 AM
To: users@subversion.tigris.org
Subject: RE: Subversion tagging
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:43:17 2007