[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Pre-commit transaction modification question

From: Brett Wooldridge <brettw_at_riseup.com>
Date: 2004-02-13 18:54:44 CET

kfogel@collab.net wrote:

>Whoa whoa whoa... Hold up one minute, Tex :-).
How did you know I was from Texas? :-)

>Let me clarify something:
>We're not suggesting that these client-side workarounds are *better*
>from the developer's point of view, nor that it's somehow more morally
>correct to simply reject the commit and force the developer to solve
>the problem before trying again.
>Rather, what we (or at least I) am saying is: the server-side-txn-mod
>solution is *hard* to implement correctly in Subversion, and the extra
>complexity it adds to Subversion may not be worth the benefit to
I agree. Let me take it as a challenge to see how simple I can make the
implementation. In the
end it may get rejected due to complexity. But complexity is a relative
thing. Adding DFS support
to Samba was complex. :-) From what I've seen of the codebase,
everything is pretty straightforward
and the implementations very concise.

>Notice that this does not deny that there is some benefit to users.
>But it also takes into account the implementation and maintenance
>burden of the feature... Which is something we think about for every
>feature. If features didn't cost anything, then this whole mailing
>list would be unnecessary.

>When we suggest workarounds, they're exactly that: workarounds. I'm
>not saying you should prefer them to the ideal solution. I'm asking
>if you can live with them, because the ideal solution may not make it
>to the top of the developers' priority stack anytime soon.
I understand. Which is why I wasn't framing it as a 'could you please
do for me', but rather as
'if I do it for you'. I know you guys have other priorities, but that's
what makes open source tick --
somebody has an itch for a feature, so *they* build it and contribute it
back, rather than waiting
for somebody else to do it for them.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 13 18:55:02 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.