> -----Original Message----- > From: BRM [mailto:bm_witn...@yahoo.com] > Sent: Thursday, May 23, 2013 10:59 > To: Varnau, Steve (Seaquest R&D); users@subversion.apache.org > Subject: Re: Tags - Symbolic names instead of Directory copy? > > > From: "Varnau, Steve (Seaquest R&D)" <steve.var...@hp.com> > > > To: BRM <bm_witn...@yahoo.com>; "users@subversion.apache.org" > > <users@subversion.apache.org> > > Cc: Thorsten Schöning <tschoen...@am-soft.de> > > Sent: Thursday, May 23, 2013 1:40 PM > > Subject: RE: Tags - Symbolic names instead of Directory copy? > > > >> From: BRM [mailto:bm_witn...@yahoo.com] > >> > >> > From: Thorsten Schöning <tschoen...@am-soft.de> > >> > >> > To: users@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@revision, (e.g., ^/trunk@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@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@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
