On 5/22/2013 4:57 PM, Varnau, Steve (Seaquest R&D) wrote:
Hi all,
I'm hoping to have slightly less controversial discussion than the
recent branches-as-first-class-objects thread. That topic did,
however, touch on tags.
As discussed previously, "tags" as a convention use the same mechanism
as the "branches" convention. The mechanism of svn cp works well for
branches. The semantics work as expected (for the most part). That is,
the results of the basic operations on the "branch" work as expected.
(checkout, update, & commit)
In my opinion, the same semantics work less well for tags. My biased
mind-set is that a "tag" is a name identifying a specific version of
code (a cross product of "branch" and "revision"). In subversion, a
directory-path@revision, (e.g., ^/trunk@123) give the correct
semantics of a tag. I can checkout the exact version of code. When I
am ready to update to a later (or latest) version of the branch,
update does the right thing. When I commit, my changes go to the right
branch, based on my checkout.
Tags are intended to be immutable. By your convention (not a bad one at
all), a tag would be a symbolic name for some part of the repository
tree at a specific revision. You could name all your tags this way,
e.g. ^/tags/trunk_at_r123 for the above-named peg revision. This would
be simpler than asking developers to remember the revision from which
they are working, then type in the appropriate syntax. If a tag becomes
obsolete (i.e. a fatal error is found in it), just delete it, then
create a new tag from the appropriate trunk revision.
But a "tag" that is the result of an svn cp (e.g.,
^/tags/TRUNK-STABLE) does not give the same semantics.
* Checkout is fine, I get the right version of the code.
* Update gives me the message that my workspace is up to date. So I
silently miss the fact that the latest code changes I wanted to
pull in are over on trunk, not on this tag I checked out from. I
think I'm working on ^trunk@HEAD, but I'm not.
* Commit does not send changes the "tagged" branch -- oh, I thought
I had an version of trunk, but my commit does not go to trunk. If
I (or my repo admin) properly protects the tags, I get an error
and realize I forgot a switch command. If my hook script isn't set
up right, it's even worse. I have a change to roll back, when I
eventually notice the mistake.
Usually only the build system (or developers trying to fix a specific
bug) will check out a tag. Developers modifying code would not check
out tags. Updating a tag, if it is immutable, is expected to be a
no-op. A pre-commit hook would prevent commits to the tag.
Due to those unfortunate semantics, we've do not use tags at all.
Whenever we want to specify a version of code, we use branch@revision.
We don't have symbolic names, but we do get the right semantics. We
have a couple hundred developers and hundreds of branches, but we do
without symbolic tags.
Yes, I know I'm stupid and that all our developers should be able to
understand how to checkout from tags and then switch instead of
update, but I think we have saved a lot of grief. (Aside from the fact
that I do not have server-side access and can't implement proper hook
scripts on our replicated repos.)
You could have the same problem by checking out a branch and then
switching to trunk. Which set of updates are you going to get? Which
set of updates are going to be committed, and to where? I avoid that
kind of confusion by not using "svn switch". But I work in a simpler
repository structure (a small number of developers with most development
on trunk).
It sounds like the root of your problem is not being able to implement a
proper pre-commit hook to make the tags directory immutable. Tools are
supposed to help perform your tasks more easily and reliably, and help
you catch the mistakes you will inevitably make. If you aren't allowed
to configure the tool to do this, it's not the tool's fault (or the
concept).
A new programmer recently asked me when she would stop making stupid
mistakes. I replied "never - I spend half of my time making mistakes
and half of my time fixing them." After 1,000,000+ lines of code, I
still make stupid mistakes. That's what testing is all about.
So, am not saying there is anything fundamentally wrong with how
"tags" work now. They just don't fit our desired semantics, so we
don't use them. I am also not saying how a better tag or label feature
should be implemented, but for our usage, a symbolic name or symbolic
link for a path@revision would be a very useful thing.
I'd say tags don't fit your repository configuration. See if you can
get a pre-commit hook that blocks modifications to the tags directory
tree within the repository.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
