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.
>
>>
>>
>> Now, you and I and everyone else on this list probably understands
>> #2 perfectly. But what about tech writers? Graphic artists? At a
>> stretch, I have been able to get them to understand checkout and
>> commit, but tags? Forget it. Too much baggage. So they get it
>> wrong. Which is easier to clean-up? A bad label, or a bad branch?
>> What if they forget the copy entirely? Put the tag in the wrong
>> place?
>
> I've seen this argument before. Are graphic artists and technical
> writers really too stupid to use source code control systems? I
> think your problem is in the way you are probably trying to explain
> tagging. I would guess you are giving them the CVS concept of a
> tag and then telling them how to implement cvs tags in Subversion.
Are you *serious* ??? Have you ever sat down and tried to explain
tags to these people. It's not terminology, it's a much more complex
concept. Sorry, they can "get" labels, they don't "get" tags. You can
_call_ them labels, and they get it then, but once you start
explaining the *how*, they just glaze over.
>
>>
>> And is this *really* too much to ask? I've seen literally dozens
>> of posts asking for this feature or something very much like it.
>> Will it destroy the "purity" of subversion, or lead to feature
>> bloat? Currently, subversion has an "svn:author" property, and I
>> cannot think of any a single argument that has been leveled
>> against labels that cannot equally apply to this property, and yet
>> no-one is proposing to deprecate this "feature".
>
> Are you serious? You don't think it's important to know who
> committed a revision.
Yes, I'm serious. And yes, I think it's important to track authors.
But, to turn the tables, why isn't the author just part of the
message field? One of the arguments against labels and/or any other
more-formal commit-time meta-data seems to be "use the message
field". Well, as I said, this seems to apply equally to the
svn:author field.
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.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 22:33:38 2006