Tim Hill <mailto:firstname.lastname@example.org> schrieb am Montag, 20. November 2006 17:28:
> On Nov 20, 2006, at 1:53 AM, Felix Gilcher wrote:
>>> One of those arguments is "not enough people have asked for it". If
>>> everyone did as you suggest, how would enough people *ever*
>>> ask for a
>>> feature? <hehe>
>> As someone else stated, this has come up on the list quite a few
>> times. Lots of people asked for it. One of the major problems is
>> that noone was able to write a specification of how this feature
>> should behave exactly (let alone how to implement it). There even
>> was a disagreement between the people that asked for labels on what
>> the term "label" implies and how this should work.
>> Writing such a specification and get a consensus that it would be a
>> worthy addition to the subversion feature set would be a first step
>> to get the feature implemented. Volunteers one step ahead please.
>> Writing the actual code or putting a bounty on that feature might
>> help as well, but as stated in the hacking guidelines even a
>> working patch is no guarantee that the feature will be accepted.
> A perfectly valid point -- however, any discussion is bound to
> generate a lot of debate over the desired shape of a feature; I
> regard that as a sign of a vibrant active user community (which is
> good). Of course, I won't comment on the fact that, if the "label"
> feature was so ill-defined in the discussions, how were so many
> people so certain that it wasn't desirable (hehe)?
Well, one of the major points against tags was always that there never was a formal proposal that everyone could agree on. And a feature with undefined behaviour is per definition of questionable value ;). Having a proposal could help showing the use cases and the expected benefits - maybe this convices a majority of the devs.
See this thread alone:
- some see labels as a simple "revision alias". Probably simpler to implement than other solutions, but I doubt the usefulness (means that I can live happily without).
- others imply that a label is an alias for url@revision. Which gets you into pretty nasty corner cases if you have several projects/components in one repository...
> I'm more than happy to work up a formal proposal, and even happy to
> do the work on a patch. However, as you noted, patches don't always
> get accepted, and I would rather have at least some consensus on a
> feature before spending a lot of time working on it.
If a formal proposal gets accepted on the dev list, chances should be pretty high that a patch that holds to their coding standard gets accepted. Not that I may speak for the devs (not even being one), but this is the procedure laid out in the hacking file. It seems to me that a proposal (or at least a good draft) is required in this case to even achieve some consensus.
> In any case, as has been suggested elsewhere in this thread, it's
> quite possible that what is really the issue here is that tags, in
> their current form, are incomplete.
Perhaps it's the "tags are not labels but copies" paradigm that needs some time to get used to. I did have my hard time at first but really like it that way.
Head of IT Development
Exozet Berlin GmbH
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Nov 20 18:33:41 2006