Re: Is label support in future release?

On Nov 17, 2006, at 12:58 PM, Danny van Heumen wrote:

>> Nope, that's not how "mutable labels" were defined when someone
>> coined
>> the phrase earlier in this thread. The term was used to define
>> moving
>> the label from one revision to another, not changing the code in that
>> revision. The latter is a branch, and should always be treated as
>> one. The code in a "label" could never be edited, as a label is just
>> a pointer to a rev, not a copy of it that could be edited.
>> No, I said not JUST an earlier revision. It's a COPY of that earlier
>> recision, with its own potential for history, and in a different
>> location.
>
> So, in fact your main reasons for not acknowledging a copy as label
> is:
> * You can't insert an alias as revision number.
> * It has it's own history, and thus (I guess you don't really mind
> the history, just the fact that you can do more than just point to
> existing files and revisions)
> * It can potentially be used for branching purposes by modifying
> the "label"-contents and therefore it can not be a label.
>
> The latter one is important isn't it?

It is important, and it's trivial to write a pre-commit hook script
to disable commits that attempt to modify tags via pathname matching.

To all people who have heard this discussion so many times over the
years, and are as sick to death of it as I am, I apologize in advance
for prolonging this thread.

-- 
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org