Brett Wooldridge <brettw@riseup.com> writes:
> Yes, I agree, to anticipate your arguments, it could have been
> implemented as a header check
> which rejected files with improper notices. Thus putting the onus on
> developers to obtain the proper
> notice and put it in files they checked in. To which I would ask
> "Why?". Why should developers
> have to do that if that is something that a tool can do for them.
> That is why we have tools; to
> help eliminate repeatitive and automatable tasks. If we had written a
> 'bad' hook that mucked up
> the files, it's our repository, it's our fault.
>
> This is like a basic liberatarian principle. Don't protect me from
> myself. Let me have the power
> and flexibility to make the changes I see fit in my environment. In
> no way does this violate the
> integrity of transaction or compromise the integrity of the
> repository. It can be implemented in
> a way that is completely transparent to the user and is literally a
> no-op when the transaction
> goes un-modified.
Whoa whoa whoa... Hold up one minute, Tex :-).
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
users.
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.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 13 16:14:08 2004