[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tags - Symbolic names instead of Directory copy?

From: BRM <bm_witness_at_yahoo.com>
Date: Thu, 23 May 2013 07:22:41 -0700 (PDT)

> From: Thorsten Schöning <tschoening_at_am-soft.de>

> To: users_at_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_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 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.

Received on 2013-05-23 16:23:17 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.