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_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 I’m
> working on ^trunk_at_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_at_revision. We don’t have symbolic names, but we do get the
> right semantics.
branch_at_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_at_revision would be a very useful thing.
But you could simply use tags/TRUNK-STABLE_at_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.Schoening_at_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
Received on 2013-05-23 08:49:45 CEST