Tags - Symbolic names instead of Directory copy?

[Varnau, Steve (Seaquest R&D)]

Hi all,

 

I’m hoping to have slightly less controversial discussion than the recent branches-as-first-class-objects thread.  That topic did, however, touch on tags.

 

As discussed previously, “tags” as a convention use the same mechanism as the “branches” convention. The mechanism of svn cp works well for branches. The semantics work as expected (for the most part). That is, the results of the basic operations on the “branch” work as expected.  (checkout, update, & commit)

 

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”). In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. I can checkout the exact version of code. When I am ready to update to a later (or latest) version of the branch, update does the right thing. When I commit, my changes go to the right branch, based on my checkout.

 

But a “tag” that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give 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. 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. I think I’m working on ^trunk@HEAD, but I’m not.
• Commit does not send changes the “tagged” branch -- oh, I thought I had an version of trunk, but my commit does not go to trunk. If I (or my repo admin) properly protects the tags, I get an error and realize I forgot a switch command. If my hook script isn’t set up right, it’s even worse. I have a change to roll back, when I eventually notice the mistake.

 

Due to those unfortunate semantics, we’ve do not use tags at all. Whenever we want to specify a version of code, we use branch@revision. We don’t have symbolic names, but we do get the right semantics.  We have a couple hundred developers and hundreds of branches, but we do without symbolic tags.

 

Yes, I know I’m stupid and that all our developers should be able to understand how to checkout from tags and then switch instead of update, but I think we have saved a lot of grief. (Aside from the fact that I do not have server-side access and can’t implement proper hook scripts on our replicated repos.)

 

So, am not saying there is anything fundamentally wrong with how “tags” work now. They just don’t fit our desired semantics, so we don’t use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing.

 

-Steve

 

 

 

[David Chapman]

On 5/22/2013 4:57 PM, Varnau, Steve (Seaquest R&D) wrote:

Hi all,

 

I’m hoping to have slightly less controversial discussion than the recent branches-as-first-class-objects thread.  That topic did, however, touch on tags.

 

As discussed previously, “tags” as a convention use the same mechanism as the “branches” convention. The mechanism of svn cp works well for branches. The semantics work as expected (for the most part). That is, the results of the basic operations on the “branch” work as expected.  (checkout, update, & commit)

 

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”). In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. I can checkout the exact version of code. When I am ready to update to a later (or latest) version of the branch, update does the right thing. When I commit, my changes go to the right branch, based on my checkout.

Tags are intended to be immutable.  By your convention (not a bad one at all), a tag would be a symbolic name for some part of the repository tree at a specific revision.  You could name all your tags this way, e.g. ^/tags/trunk_at_r123 for the above-named peg revision.  This would be simpler than asking developers to remember the revision from which they are working, then type in the appropriate syntax.  If a tag becomes obsolete (i.e. a fatal error is found in it), just delete it, then create a new tag from the appropriate trunk revision.

 

But a “tag” that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give 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. 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. I think I’m working on ^trunk@HEAD, but I’m not.
• Commit does not send changes the “tagged” branch -- oh, I thought I had an version of trunk, but my commit does not go to trunk. If I (or my repo admin) properly protects the tags, I get an error and realize I forgot a switch command. If my hook script isn’t set up right, it’s even worse. I have a change to roll back, when I eventually notice the mistake.

Usually only the build system (or developers trying to fix a specific bug) will check out a tag.  Developers modifying code would not check out tags.  Updating a tag, if it is immutable, is expected to be a no-op.  A pre-commit hook would prevent commits to the tag.

 

Due to those unfortunate semantics, we’ve do not use tags at all. Whenever we want to specify a version of code, we use branch@revision. We don’t have symbolic names, but we do get the right semantics.  We have a couple hundred developers and hundreds of branches, but we do without symbolic tags.

 

Yes, I know I’m stupid and that all our developers should be able to understand how to checkout from tags and then switch instead of update, but I think we have saved a lot of grief. (Aside from the fact that I do not have server-side access and can’t implement proper hook scripts on our replicated repos.)

You could have the same problem by checking out a branch and then switching to trunk.  Which set of updates are you going to get?  Which set of updates are going to be committed, and to where?  I avoid that kind of confusion by not using "svn switch".  But I work in a simpler repository structure (a small number of developers with most development on trunk).

It sounds like the root of your problem is not being able to implement a proper pre-commit hook to make the tags directory immutable.  Tools are supposed to help perform your tasks more easily and reliably, and help you catch the mistakes you will inevitably make.  If you aren't allowed to configure the tool to do this, it's not the tool's fault (or the concept).

A new programmer recently asked me when she would stop making stupid mistakes.  I replied "never - I spend half of my time making mistakes and half of my time fixing them."  After 1,000,000+ lines of code, I still make stupid mistakes.  That's what testing is all about.

 

So, am not saying there is anything fundamentally wrong with how “tags” work now. They just don’t fit our desired semantics, so we don’t use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing.

 

 

I'd say tags don't fit your repository configuration.  See if you can get a pre-commit hook that blocks modifications to the tags directory tree within the repository.

-- 
    David Chapman      dcch...@acm.org
    Chapman Consulting -- San Jose, CA
    Software Development Done Right.
    www.chapman-consulting-sj.com

[Branko Čibej]

I'm confused ... why would you need a special pre-commit hook for
something like that? I would expect access control to be good enough.
Just make the tags tree in the repository read-only for most users.


(N.B., having actually immutable tags would be a nice feature, but
they're not required to solve your problem.)

-- Brane


--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

[David Chapman]

Access controls implies more than what the original poster was asking.
Right now anyone can make a "tag" in his development environment simply
by recalling the revision number. Access controls could work and are a
reasonable suggestion in many cases. I tend not to think of them because
I usually work in more-open environments where anyone can commit.

[Andreas Krey]

On Wed, 22 May 2013 19:33:33 +0000, David Chapman wrote:
...

>
> Usually only the build system (or developers trying to fix a specific
> bug) will check out a tag. Developers modifying code would not check
> out tags.

Unless they are using externals. Letting external point to a non-tag
thing isn't good idea (because the tags you make of your project
wouldn't fix the externals to a tagged version).

And then you run into some workflow turbulence when you start modifying
within the externals.

Andreas

--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

[Thorsten Schöning]

Guten 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 I’m
> working on ^trunk@HEAD, but I’m not.Commit does not send changes the

> “tagged” branch -- oh, I thought I had an version of trunk, but my
> commit does not go to trunk.

I may be misunderstanding you but I think this is wrong. Commits of
course always go to the directory you checked out, in your case
tags/TRUNK-STABLE. If you wanted to work on trunk than I don't know
why you checked out tags/TRUNK-STABLE at all? And what's the
difference to branches? If you check out branches/someFeature your
committs wil always go to branches/someFeature and not
branches/branchWhichSomeFeatureBasedOn or trunk or whatever. There's
no difference between branches and tags, that's what the last thread
was about.

> If I (or my repo admin) properly
> protects the tags, I get an error and realize I forgot a switch
> command.

If you wouldn't protect your tags you would get the updates you were
missing before. What do you really want, immutable tags or not?

> Due to those unfortunate semantics, we’ve do not use tags at all.
> Whenever we want to specify a version of code, we use
> branch@revision. We don’t have symbolic names, but we do get the
> right semantics.

branch@revision-semantics would perfectly well work with immutable
tags, the problem is that you expect updates and commits for some
reason.

> Yes, I know I’m stupid and that all our developers should be able
> to understand how to checkout from tags and then switch instead of
> update,

Why would you want to checkout immutable tags at all? And how do you
work with non immutable branches? Why are your developers able to
switch from non immutable branches, but not from immutable or non
immutable, whatever you like, tags? That sounds a bit weird to me, but
I may simply didn't understand your point.

> but I think we have saved a lot of grief. (Aside from the
> fact that I do not have server-side access and can’t implement
> proper hook scripts on our replicated repos.)

Does this mean that the problem with invalid hook scripts denying
commit access to tags which you mentioned earlier doesn't exist and
you are able to commit to tags and getting updates, which you
mentioned as missing before and all that stuff? :-) I'm a bit
confused...

> So, am not saying there is anything fundamentally wrong with how
> “tags” work now.

Of course it's not as they work like branches and branches seem to
work for you.

> They just don’t fit our desired semantics,

I didn't understand the semantics you want from your description,
sorry.

> so we
> don’t use them. I am also not saying how a better tag or label
> feature should be implemented, but for our usage, a symbolic name or
> symbolic link for a path@revision would be a very useful thing.

But you could simply use tags/TRUNK-STABLE@someRev or wouldn't need
@someRev at all if your tags are immutable after creation.

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning E-Mail:Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[BRM]

> From: Thorsten Schöning <tscho...@am-soft.de>

> To: us...@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),

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.

However, as you've mentioned and was more at length discusses elsewhere
that's simply not have SVN works.

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
>

[Varnau, Steve (Seaquest R&D)]

> From: BRM [mailto:bm_wi...@yahoo.com]

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

[BRM]

> From: "Varnau, Steve (Seaquest R&D)" <steve....@hp.com>

> To: BRM <bm_wi...@yahoo.com>; "us...@subversion.apache.org" <us...@subversion.apache.org>
> Cc: Thorsten Schöning <tscho...@am-soft.de>
> Sent: Thursday, May 23, 2013 1:40 PM
> Subject: RE: Tags - Symbolic names instead of Directory copy?

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

[Varnau, Steve (Seaquest R&D)]

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