> This is yet again domain specific knowledge. I could certainly see
> multiple tag types being allowed, one to indicate code has been
> promoted to the QA department, one to indicate exact version of an
> integration build, one to indicate actual RTM version, and so on. Each
> of these may have naming conventions. Access to the folders to make or
> hide tags may be restricted to people in certain roles.
>
I have to agree here. I can count, on one hand, the number of times I have
used tags (labels) in the last 10 years. When our project (well over 30k
files, nearly 100 developers) is ready for QA, we have a branch setup
specifically for that. When QA finds a problem, we fix it in that branch
(not at a tag or label) and reverse integrate changes upstream to our trunk
and/or sandbox branches. Tags are not very useful for making snapshots of
the mainline. Branches are really more appropriate -- especially when
changes to that "snapshot" are required to stabalize it.
What subversion really needs is not ackward tagging/labelling support, but
merge tracking to make branches more than just marginally useful.
FYI subversion isn't used on that project, nor would it because
branching/merging is still so immature.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 28 23:26:22 2004