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

Re: Is label support in future release?

From: Ryan Schmidt <subversion-2006d_at_ryandesign.com>
Date: 2006-11-17 23:53:31 CET

On Nov 17, 2006, at 15:32, Tim Hill wrote:

> On Nov 17, 2006, at 8:43 AM, Jeremy Pereira wrote:
>
>> On 17 Nov 2006, at 01:14, Tim Hill wrote:
>>
>>> Solution 2: A tag. But wait; creating a tag takes a copy
>>> operation, which is a commit. I *cannot* do my foo.c commit and
>>> then follow this with a tag operation, since these are two
>>> distinct commits. So I _must_ create the tag in my working copy
>>> and then commit both the tag and the fix at the same time. The
>>> workflow is:
>>
>> You are allowed to put a comment on an svn copy operation you
>> know. You could even use the same one as for the commit of the
>> change if you really wanted.
>
> My point is I *have* to commit the copy and the fix at the same
> time, else how can the tag truly reflect the point in time where
> the fix occurred? If I commit the fix and *then* create the tag I
> have two distinct commits, and there always exists the possibility
> of another commit sneaking in between the first and the second:
>
> -- (dev A) svn commit foo.c
> -- (dev B) svn commit foo.c
> -- (dev A) svn copy foo.c $TAGS/.....
>
> Here, dev A thinks the tag refers to the rev of foo.c he checked
> in. But it doesn't; it refers to the subsequent rev checked in by
> dev B, who "sneaked in" the update between dev A's two commits.

Which is why you specify the revision you want in the copy command so
that it doesn't matter.

-- (dev A) svn commit foo.c
=> Revision 41 created
-- (dev B) svn commit foo.c
=> Revision 42 created
-- (dev A) svn copy -r 41 foo.c $TAGS/.....
=> Revision 43 created
=> No problem

> I'm sure I'm coming over as belligerent in this discussion, which
> is unfortunate, since I don't want that. But I do get a sense of
> confirmation bias here, which is unfortunate. Subversion is a great
> product, I like it, use it, and promote it. But it has its weaker
> points, and tags, imho are one of them. Labels aren't great,
> either, but until tags get better, people like myself are going to
> continue to want labels.

Yeah, I'm sure part of the reason for this resistance is that there
are many people subscribed to this list who like myself have used
Subversion for years and understand now how it works, what the
"Subversion way" of doing things is. Most new Subversion users who
post to the list saying that something is broken have merely
misunderstood how to use Subversion properly, which is then explained
to them. And when new people come onto the list and make suggestions
that involve large changes to Subversion, the natural reaction has to
be "no, it's not necessary to make such changes; here's how we do
that with the current version of Subversion."

Developer time is scarce, and the most important changes get made
first. The developers get to decide what's important, because it's
their time. Implementing large new features (labels) is unlikely to
be deemed important enough when many will say that existing features
(tags, properties, a little scripting) can be used to achieve a
similar result. That's not to say that nobody thinks labels are
important; rather, it means that the available developers seem to
feel that other issues, such as merge tracking or true renames which
have also been requested many many many times, are more important.

As has been mentioned before, there's also the matter of defining
exactly what the hypothetical labels feature would do, how it works,
how one uses it. In this thread again (as in most of the previous
threads on the topic) there has been disagreement on this point.
Until agreement on specifications is reached, coding cannot begin.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 23:54:18 2006

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.