[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tags - Symbolic names instead of Directory copy?

From: BRM <bm_witness_at_yahoo.com>
Date: Thu, 23 May 2013 10:58:49 -0700 (PDT)

> 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.


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:

@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.


Received on 2013-05-23 19:59:28 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.