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.
[...]
> 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.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417359
Received on 2009-11-13 03:39:48 CET