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