> -----Original Message-----
> From: BRM [mailto:bm_witness_at_yahoo.com]
> Sent: Thursday, May 23, 2013 10:59
> To: Varnau, Steve (Seaquest R&D); users_at_subversion.apache.org
> Subject: Re: Tags - Symbolic names instead of Directory copy?
>
> > From: "Varnau, Steve (Seaquest R&D)" <steve.varnau_at_hp.com>
>
> > To: BRM <bm_witness_at_yahoo.com>; "users_at_subversion.apache.org"
> > <users_at_subversion.apache.org>
> > Cc: Thorsten Schöning <tschoening_at_am-soft.de>
> > Sent: Thursday, May 23, 2013 1:40 PM
> > Subject: RE: Tags - Symbolic names instead of Directory copy?
> >
> >> 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...
>
> One way to do that would be to have another directory that you have the
> hook scripts configured to make read-only.
> So:
>
> /trunk
> /branches
> /tags
> /tags-readOnly
>
> Again, you're going to a hook-script to do it as that is how SVN
> enforces it best.
> Yes, there is the permissions structure but there's no easy way to do a
> globular matching like the following:
>
> [/*readOnly*]
> @users = r
>
> That is certainly one feature that would be very handy if ever
> implemented.
>
> >> 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.
>
> It does and it's called svn:externals.
> You can even do:
>
> path_at_revisionA -r revisionB
>
> At work I have a series of projects that make up a "distributed" system.
> Each project has its own trunk/tags/branches.
> I have a separate tree where all I do is define svn;externals to certain
> versions in order to make System Releases.
> It works very very well.
>
> $0.02
>
> Ben
Ahh, using externals to make baselines, rather than to pull from multiple projects. I like that idea.
I have managed to avoid using externals 'til now, but that is a good reason to explore them.
Thanks,
-Steve
Received on 2013-05-23 20:06:00 CEST