John,
I see your point in explaining how CVS branching and its relation to the
dot-dotting, that's not new for me.
In CVS, if I tag a file (or a bunch of files) this operation is reversable
without any notice in the repository at all. Worse, a tag can be moved to
a different revision which makes such tagging rather useless from the
reproducibility perspective.
In Subversion, a tag can be moved or removed as well, but I can always
reconstruct an overwritten directory, whether it is in /trunk or /tags.
In Subversion, the precise location of a file is constructed of two
things: its location (path) in the repository and its revision number.
Tagging just changes the path but cannot guarantee that the contents will
always be the same and can be referred to in this way unambiguously. This
only holds if you additionally count for the revision number.
So: It's not enough to mention the more-or-less literal tag. If you
consider arbitrary repository operation (excluding dumpfilter, property
changes of elder versions or other repository destruction) you always have
to consider that a tag or branch is removed (not appropriate anymore),
renamed (restructuring maybe) or re-created (similar bug, next attempt to
fix it). When I describe a tag in a documentation, I always (have to) give
the revision as well:
"The issue is solved in rev. 105 of
http://server/repos/tags/project-x-release5/"
Sparing the revision number when referring to it, like in this statement,
makes it nothing better than CVS' tagging like "the tag may be there and
may be the same - bet on it!"
Tell me what you think.
- Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 4 18:24:07 2005