> From: BRM [mailto:bm_witness_at_yahoo.com]
>
> > From: Thorsten Schöning <tschoening_at_am-soft.de>
>
> > To: users_at_subversion.apache.org
> > Sent: Thursday, May 23, 2013 2:49 AM
> > Subject: Re: Tags - Symbolic names instead of Directory copy?
> >G uten Tag Varnau, Steve (Seaquest R&D), am Donnerstag, 23. Mai 2013
> >um 01:57 schrieben Sie:
> >
> >> 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”).
> >
> > I don't see the point, as you already know that it's not handled that
> > way in Subversion and you need to make the same conclusions for tags
> > and branches.
> >
> >> In
> >> subversion, a directory-path_at_revision, (e.g., ^/trunk_at_123) give the
> >> correct semantics of a tag.
> >
> > Simply use them that way, like you said for branches.
> >
> >> But a “tag” that is the result of an svn cp (e.g.,
> >> ^/tags/TRUNK-STABLE) does not give the same semantics.
> >
> > Because from my understanding you compare two things which have
> > nothing to do with each other: One is how branches and tags are
> > created, both the same way, but the other is what happens afterwards
> > to each. As branches and tags are technically the same, only differing
> > by convention, they of course work equally and therefore need to share
> > 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.
> >
> > Only if it is update, meaning no one ever committed anything to your
> > tag. If commits were made, your working copy would not be up to date
> > anymore, of course. It sounds to me like you compare branches with per
> > convention immutable tags to come to the conclusion that both have
> > different semantics. But that's not the case, just a result of your
> > immutable tags convention.
> >
> >> 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.
> >
> > Because with checking out a tag and keeping it immutable you want that
> > tag and not trunk. Or what's the reason for checking out that special
> > tag at all? Especially if you know it's immutable, if it wouldn't be
> > immutable you of course would get new commits.
>
> I think he's thinking of CVS style tags, which are mutable in that you
> can modify which version of different files have the tag. So everyone
> works on HEAD and a "STABLE" tag progresses across it as developers
> decide different ports are stable.
My example was a poor choice, as I prefer non-mutable tags, but there are certainly use-cases for mutable and non-mutable. There are certainly examples from other versioning tools. "Baselines" concept in ClearCase, that can be defined then locked. But those get too complex very fast. I really prefer the kind of simplicity in Svn.
>
> However, as you've mentioned and was more at length discusses elsewhere
> that's simply not have SVN works.
Agreed. I understand how Svn works, and it's fine how it works. But I'm arguing that I'd like to see an additional type of object that would be useful...
>
> A similar kind of workflow for SVN would be:
>
> Main work: /trunk
> Trunk Stable "tag" or branch: /tags/trunk-stable or /branches/trunk-
> stable
>
> Do work in /trunk, as things are declared "stable" merge to
> /branches/trunk-stable.
>
> While I have in the past been able to sympathize with people looking for
> CVS-style tags (and still do to some extent), I think Subversion style
> Tags are far more superior primarily from the fact that you can track
> any changes that are happening to the tag, which you could not do with
> CVS.
>
> Ben
> >
Subversion implements a versioned filesystem model (add, cp, mv, rm). If it also had a notion of a symlink (ln) that allows reference to path_at_revision, then it gives the same tracking of changes to a "tag" that you mention. But then other operations like checkout operate on what it points to. Then you really get baseline-label-tag type semantics instead of branch semantics. And to get those semantics, you don't really need hook scripts or special permissions to treat them specially.
-Steve
Received on 2013-05-23 19:42:10 CEST