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