On 3/20/06, John Calcote <john.calcote@gmail.com> wrote:
> Jim Blandy wrote:
> > But I'd also specifically like to hear from John Calcote, too. John,
> > what are you trying to do with Subversion at the moment that
> > Subversion's tags handle poorly, but that symbolic names for revisions
> > would do well?
> >
> My use of tags in Subversion is admittedly naive. I've been using them
> to simply assign a symbolic name to a revision (a snapshot in time).
> This is the most basic of use cases provided by CVS tags, and is in fact
> the documented use of tags in the CVS manual. That being the case,
> Subversion's way of managing tags is overkill for my purposes. I don't
> need to branch the project. I just need to flag a particular numerical
> revision as a special case.
Yes, this is the "simplistic" form of tags that many times gets people to
think that this is so trivial. The problem is that when you get into larger
projects, even the "simple" things get to be not so simple. (Darn those
details... life would be so much simpler without details...)
> Speaking of branches, I would also like to see tags implemented such
> that people cannot commit a change from a work area produced from a tag
> - under any conditions. A work area produced from a tag should be
> limited to a snapshot in time and/or space. Anything else defeats the
> general purpose of tags - to get back to a certain point in time for
> historical purposes. Before I get flamed for this remark, I'll qualify
> it by saying that I'm sure other people are doing things with tags that
> would be broken by such a rule. But there are sound fundamental software
> engineering concepts behind this desire. I'm not saying that branching
> from a tag should be disallowed. I'm only saying that people should have
> to make a conscious decision to do so. Which means that a branch must be
> created from a work area produced from a tag before a change to that
> work area could be committed.
I also wish there was a way to make "tags" (branches) immutable in
an easy way. Turns out that it is not quite as easy if you need to
support mixed revisions due to the way the transaction is built. However,
if you take a look at my pre-commit hook, it makes the /tags/ and
/releases/ trees immutable:
http://svn.code-host.net/svn/Insurrection/trunk/.htauth/pre-commit
(/releases/ is where we put tags when it actually gets placed into the field)
(NOTE - Yes, you can add to a tag but you can never modify one - the
reason for the "add" hole is that in order to support structured tags
I had to support adding at any level. I am sure that could be locked
down some more once the structure of the tags tree is known.)
> This discussion has taught me a lot about the way other people use tags,
> and I'm inclined to think I might revise my use of tags in the future to
> include some of these other uses, so I would at this point tend to agree
> with a lot of people on this thread that simple symbolic names for
> revisions is not enough. Regardless, I would still like to see whatever
> comes of this discussion provide a lighter-weight mechanism for managing
> simple symbolic revisions.
I think that many people had covered that ground you just described.
You just happen to have described it rather nicely here. The problem
set gets complicated rather quickly, especially when you start having
really complex projects with complex tagging requirements.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 20 21:43:34 2006