Greg Stein wrote:
> On Mon, Nov 29, 2004 at 11:41:32AM -0500, Greg Hudson wrote:
>> On Mon, 2004-11-29 at 11:29, Greg Stein wrote:
>>>> If we do want a paranoid-comparison flag at all (do we?), there's no
>>>> reason
>>>> for it not to be common to *all* subcommands which crawl a WC.
>>>
>>> Make paranoid the default. We always want to choose safe defaults. If
>>> somebody wants a bit more speed at the cost of "not [necessarily] as
>>> safe", then they can use a flag.
>>
>> So you're suggesting every Subversion operation which crawls a WC should
>> read every byte in the working copy, just to be safe?
>
> Don't be antagonistic, please. I was speaking in reference to revert.
> Not other commands.
Not to be antagonistic, but: Why should revert be different?
If status will not tell you about it, diff will not diff it, and commit will
not commit it, why should revert revert it?
Revert is not a last-ditch cleanup command, it's a perfectly routine
operation when reviewing changesets, and should not be unduly penalized.
>> We're not talking about "a bit more speed" here. We're talking about
>> the difference between acceptable and unacceptable performance for a
>> moderately-sized working copy.
>
> Euh. I know that. And I'm saying that I believe the default should be
> safe, even at the cost of being a bit slow. If the user knows the
> funky edge cases are not present, then they can pass a switch to speed
> up the operation [at the cost of possibly missing things to revert].
I think that this is not a sensible default.
If you make the default behaviour *intolerably* slow, users will script
around it, and defeat your attempt to foist extra almost-always-unnecessary
checks upon them. Consider the typical use of subversion - if you start
making wide use of non-timestamp-affecting programs, then you've broken the
whole concept of 'make'.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 29 18:30:44 2004