On May 9, 2005, at 5:33 PM, Tim Hill wrote:
> Well, I for one think labels would be "safer", even if it might not
> be "impossible to accidentally revision-labels".
Oops, sorry about the typo. :-)
It should read "impossible to accidentally change revision-labels",
but I'm sure you noticed that.
>
> If labels were well-known directory properties, a change to a label
> would be a normal logged change to a repo. Technically, that makes
> it on a par with an accidental change to a tag as far as logging
> and noticing changes. OTOH, with file changes going on all over the
> place, a label change is more likely to be noticed (manually or
> automatically) than a file checkin, since such a change is first-
> class, rather than second-class.
I'm not sure I understand. Why would a property-change commit be
more likely to be noticed than a tag-directory commit? You seem to
have some definiton of 'first class' and 'second class' here that
isn't explained. In my mind, users would get commit emails whenever
something changed, no matter what it is.
>
> I don't think a good, usable label design *has* to make the kinds
> of guarantees you seem to be demanding. Tags certainly do not --
> and your arguments against labels could be applied equally to them.
I only made my original remark because it was suggested that the
current implementation of tags were "unsafe", and that somehow labels
would be "safer"... and I don't believe it. For what it's worth, I
100% agree with what you say, that label and tag designs don't need
to make such guarantees. I'm simply trying to refute the notion that
labels would be "safer" than the status quo. And I guess I'm
preaching to the choir. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 10 02:39:43 2005