Mike Samuel wrote:
> 2009/11/12 Branko Čibej <brane_at_xbc.nu>:
>
>> Mike Samuel wrote:
>>
>>> And I would prefer to avoid adding a new property like svn:text just
>>> to work around tricky but ultimately fixable UTF-16/32 issues.
>>>
>>>
>> The key phrase you're missing is "maintainable for the long term," see
>> my other post. Remember that this project is mostly run by volunteers;
>> any solution to tricky issues must be such that expected maintenance
>> costs vs. perceived gains are low enough that it stays maintained even
>> if the original implementer goes away. There's nothing inherently wrong
>> with your proposal, but its implementation would have to take that into
>> account; and that's also an incentive to keep things simple.
>>
>
> I absolutely agree with everything you said, except your implication
> that a new property is inherently simpler than fixing a bug in the
> interpretation of an existing one.
>
You'll notice that issue #1002 is classified as a "feature" not as a
"bug". I tend to agree. There is no bug in the current behaviour. There
is a well-documented limitation.
I spelled that out because you seem to assume that "fix a bug" implies
"small change to existing behaviour," and rule out "introduce new
feature." It wouldn't be a new feature as much as a different, simpler
implementation of an existing one.
Even the original solution proposed in the issue is just a short cut
that effectively shifts the burden from SVN developers to SVN users.
>> [...]
>>
>>
>>> What are next steps? Do we put things to a vote, duel, appeal to a
>>> higher power?
>>>
>>>
>> We keep discussing and addressing each others' concernes, until we reach
>> some kind of agreement. The "higher power" you refer to is the project's
>> developers, i.e., a vote; but the choices have to be a lot more
>> clear-cut before that makes sense. We don't usually vote on abstract
>> design concepts, and certainly not after only a few hours of discussion.
>>
>> You could /also/ try the proof-by-code method; provide a patch for
>> review, or ask for a branch to implement your proposal on. It makes
>> sense to convince others that your design is practical first, though;
>> otherwise you could end up writing a lot of code that never gets
>> integrated into the mainline.
>>
>
> That's exactly what I'm trying to do :) Instead of dumping a patch on
> the list and pressuring people to accept my design because otherwise
> my coding would be wasted, I'm trying to be a good citizen and hash
> out the disagreements first. But I am leery of scope-creep -- I don't
> want fixing a bug to turn into a discussion about a new context
> sensitive merging system.
>
Like I said -- this is all, from my point of view, a discussion about
context-sensitive merging; or more specifically, about how to get the
"context" part right all the time instead of just most of the time.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417369
Received on 2009-11-13 04:06:09 CET