On 26-Feb-06, at 2:58 PM, Rob van Oostrum wrote:
>> -----Original Message-----
>> From: Scott Palmer [mailto:scott.palmer@2connected.org]
>> Sent: Sunday, February 26, 2006 1:42 PM
>> To: users@subversion subversion
>> Subject: Re: I, too, miss tags.
>>
>>
>> On 26-Feb-06, at 1:15 PM, Rob van Oostrum wrote:
>>
>>> Here's my thinking on this discussion:
>>>
>>> - Unless you have a trunkless/branchless repository, simply creating
> a
>>> textual alias for a revision number is useless in terms of using it
>>> as a
>>> tag to refer to a specific version of your application.
>>
>> Why?
>
> Because adding a "version_1_0" label for revision X to the root of a
> repository that contains many branches will not tell you anything.
> What
> branch in that revision actually contains version_1_0 of your
> application? What if your repository contains multiple modules, each
> potentially containing many branches?
As I stated elsewhere, I would put the labels in the branch being
labeled, where they belong.
>>> - Mapping a URL+revision pair to a label in a versioned property
> does
>>> exactly the same thing as 'svn copy trunk tag' would.
>>
>> No. It wouldn't label the trunk, it would make a new copy of it.
>> Forcing the use of --stop-on-copy which leads to...
>
> Actually, it only creates a pointer to where you copied from. I don't
> understand what the inconvenience is in also having on-the-spot access
> to a full copy of the tag. Furthermore, svn log -v --stop-on-copy
> [tag]
> should only ever return one revision, which will also give you the
> commit message telling you why, when and by whom the tag was
> created. If
> a tag was created off another tag, it will also let you dig further
> down. All things you wouldn't have with flat labels.
Why wouldn't I have this with "flat" labels? They would be part of a
commit like anything else - with a log message and user name.
>> It's pretty clear from this discussion that tags are an awkward hack
>> to get at the functionality that people asking for "labels" really
> want.
>
> Clear & awkward to you perhaps. For the past 2 years, I've managed SVN
> repositories for a couple dozen large multinational accounts, quite a
> few of which are many Gigabytes large and contain in excess of 40k
> revisions each.
Gigabytes in your repo and the magnitude or your revision numbers are
relevant how?
I've been using Subversion without this feature too - everyone that
uses Subversion has.
> We initially migrated from CVS to SVN *specifically*
> because one large client ran into a scalability issue directly related
> to CVS' implementation of tags. Ironic?
Wouldn't know, I care nothing about CVS. We aren't discussing CVS.
>>
>> I don't follow what you are getting at.
>
> Dir A ---> tag X (added in r200, removed in r210, re-added in r250,
> removed and re-added in r301 and r302)
> Dir B
> Dir C
> - foo (added in r100, removed in r201 and re-added in
> r300)
>
> How would your simple wrapper implement these scenarios:
>
> 1) r200 of tag X: should contain r100 of foo
> 2) r250 of tag X: should not contain foo
> 3) HEAD of tag X: should contain r300 of foo
>
> It's easy enough if you always grab from Dir A (that is only even
> possible if you always know where each tag happens to have been
> stored).
> But what if I say: give me the revision of foo corresponding to tag
> X at
> revision 250? Assuming foo even still exists on HEAD, your wrapper
> would
> have to go up from foo one directory level at a time and
> recursively (or
> should that say reverse-recursively ;) check each parent at EACH
> qualifying revision for the presence of tag X.
>
> The cumbersome svn copy trunk tag approach already gives you all of
> this
> without an ounce of the trouble.
Tag X is tagging project A. A tag only refers to a single revision
number at any point in the branches history. r200 of tag X will refer
to r200 or earlier of the branch, r250 of tag X will refer to r250 or
earlier of the branch.. the version of 'foo' in that branch is
available via the current means that subversion provides. Tag X is
NOT labeling 'foo', it is labeling A, which contains some version of
'foo'. If the labeling script/tool/feature is built to walk up the
tree until it finds a matching label (likely to be a short and very
quick walk), you could ask for "Dir A/foo" at tag X and get what you
were after. I don't see a problem.
> Of course SVN is incomplete. So is every other application ever
> written.
>
> You don't need hook scripts to get any of the functionality suggested.
> They would merely help you enforce restrictions on the use of the
> repository.
Without enforcing those restrictions you simply have to trust that
tags really are tags and ont something completely different... a
strange way to work.
> Why would you want to label a revision?
It's a reference point. There could be many reasons.
> Unless your repository has no
> branches/tags and only consists of one codeline, the revision is going
> to refer to any number of copies of your codebase.
Huh?
> What would the point in that be?
Well, that's not what labels would be so I suppose that would be
pointless, but irrelevant.
>> Tags are TOO flexible, there is nothing enforcing that
>> they make sense. I can copy the trunk of ProjectA into the tags
>> directory or ProjectB and then when I try to use the tag as a basis
>> for merging or rebuilding an old release on ProjectB everything will
>> be hosed.
>
> Huh? You must be doing something completely wrong.
But when I'm labeling I don't want to be able to do something
completely wrong. That's my point, I can do "svn cp ProjA/trunk
ProjB/tags/Version1" and get a useless "tag" for ProjB that will
make no sense in the context of ProjB.
As a cheap-copy branch it is fine, subversion can't know that it is
not what I want, there may be cases when that is what I want. As a
label it is ridiculous that it is even possible.
> I only say this
> because I depend on tags for the exact same things (i.e.
> reconstructing
> version of a codebase, determining the from/to of merges, etc) many,
> many times a day. There is nothing it will not let me do.
That's what I meant when I say they are TOO flexible for labels.
> The SVN developers have been working on this for quite a few years
> now.
> They are some of the smartest people in SCM development you'll find
> anywhere. When met with such broad disagreement, try not to assume
> that
> everyone else is wrong or not "getting it". Try and think about why so
> many people that are bound to be smarter than both you and I are
> saying
> that you're wrong.
Why are YOU assuming that the people asking for the feature are
unintelligent, or not as smart as, the subversion developers? Or
maybe you and I are the only idiots that are "bound to be stupider"?
Anyone participating on this list should be smart enough that this
"problem" could be explained away if it truly didn't exist. But we
are still here. Are we just complete morons? If we are stuck in a
rut eventually someone should be able to provide that little bit of
information needed for use to get un-stuck.
> You might actually learn something ;-)
I like learning :). I'm open to the discussion, I may come around to
suddenly realizing that tags are exactly what I want and I've been
wrong all along, when/if that point comes I'll apologize and go
happily on my way... but I think that fact that many people struggle
with this and that it constantly comes up on this list means that
something about the process is lacking something or the concept of
Subversion's tags is unclear in some way. These discussions are
helpful to find out if there is really a missing feature or get at
the root of the misunderstanding about the feature that is there.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 27 19:18:07 2006