2009/11/12 Branko Čibej <brane_at_xbc.nu>:
> 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.
I'll stop calling it a bug then.
I do want to keep the scope of my changes small though. I am simply
not familiar enough with svn's codebase in particular or with patch
theory in general to be competent to bite off implementing a new
feature.
This may be too large a problem for me to attempt to solve, but if so
I do not yet understand why.
> Even the original solution proposed in the issue is just a short cut
> that effectively shifts the burden from SVN developers to SVN users.
True. My solution may shift the burden to users, but it builds on an
existing well understood/standardized mechanism. Shifting the burden
onto developers by adding more moving parts is fundamentally different
from building on standards parts that they are already familiar with.
>>> [...]
>>>
>>>
>>>> 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=2417373
Received on 2009-11-13 04:13:57 CET