Dirk Schenkewitz wrote:
> Daniel Patterson wrote:
>
>>
>> The problem with a label is that it's going to have to inherit all
>> the abilities that the current "recommendation" has. It's going
>> to need history of it's own. It's also going to have to be able
>> to deal with mixed-revision tags, which the "copy workspace to URL"
>> does quite intuitively. That all sounds like a lot of repeated
>> work.
>
>
> No, as far as I understand, labels/aliases/mnemonics *must not* have
> a history, exactly as a SVN revision number does not have a history.
> The question "What was r54236 like at r77654?" makes no sense, exactly
> as "What was Build_2004-05_custom_special like at r77654?" makes no
> sense if "Build_2004-05_custom_special" is the alias for r54236.
I don't agree. Unless you reload the repository, r54236 will always
refer to the same revision of the same files. Labels as people are
throwing around, can change. That specific alias probably wouldn't
change but "released_to_customers" most certainly would. There are
times you might want to know what "Build_2004-05_custom_special" looked
like before someone re-aliased it to fix a missing file issue.
While I think that having aliases map directly to a revision number
would help a certain set of people, they would be less than useful to a
different set, and add unnecessary complication to a third set of people.
Multi-project repositories don't work well with this concept. There can
be only one "Release_1.0" alias, but not all projects are going to reach
this point at the same time.
People who do mixed-revision releases wouldn't find this concept a fit
either.
I'm not saying the concept has no value, but rather that the
implications aren't as clear-cut and simple as the implementation you're
thinking. I'd like to see something like this that doesn't have as
limited a scope, but that would be much more complicated.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 11 21:16:36 2005