> 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
