2009/11/12 Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>:
>
> On Nov 12, 2009, at 8:43 PM, 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.
>>
>>> [...]
>>>
>>>> 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.
>
> [ disclaimer: I know zero about the technical issues at play here, but I've done a lot of poking around in the Subversion code base. ]
>
> I think the point Brane is trying to make, and one that I'm supportive of, is that as a community, we aren't comfortable with simple fixes which scratch a particular itch, but end up costing us big in the long run. Â Those costs generally come in the form of added maintenance burden down the road. Â I've spent the last year of my life coding around one-off hacks in the working copy library; it ain't purty.
> That being said, it's great to see you getting involved with the community in working to address your problem. Â We want to help you, but with as large of an establish code- and user-base as Subversion, there's just a bit more thought that needs to go into even seemingly simple features.
Agreed. I posted this idea for criticism and I think the criticism
it's received is entirely appropriate.
That said, it's hard to respond to nebulous claims like "one-off
hacks", "maintenance burden", etc. I've asserted that this is
updating the interpretation of svn:mime-type which is a
well-documented standard and is widely understood by developers, so I
think the chance for user-surprise is low. I've yet to see a
refutation of that claim, and it seems clear to me that adding new
property types with unclear semantics is exactly the kind of
maintenance headache you describe.
> /me goes back to his cave to hack on libsvn_wc.
>
> -Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417379
Received on 2009-11-13 04:22:09 CET