On 3/20/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 3/19/07, Erik Huelsmann <ehuels@gmail.com> wrote:
>
> > No, we're using the timestamp too. But Ben took a position where he
> > says 'timestamps should have been enough', so in effect we're giving
> > over-service (we're doing more than we should be expected). That's why
> > I say we're stretching it.
>
> We've had a policy (since the beginning) of not acknowledging tools
> that change file contents without changing the timestamp. The 2 or 3
> times we've discovered such tools, we've always shouted them down as
> dangerous and broken, and they've been fixed. I don't see the latest
> complaint as anything new.
>
> In this particular case, it looks like Erik came up with a way to look
> at *both* timestamp and filesize on the first logical pass (rather
> than just timestamp), and this fixes the problem for these folks,
> without adding any extra stat() calls... which is great. But there is
> *no way* we should give up our speed optimizations for 99.99% of the
> universe just to prevent dataloss for the .01% of tools that blatantly
> flaunt convention. In this case, it looks like we didn't have to
> choose between performance and support for broken tools... but it ever
> comes down to that, I'll put my foot down. :-)
>
> So I think the folks who filed the issue should consider themselves
> 'lucky' that we were able to accomodate their brokenness without
> hurting performance.
Ok. I closed the issue commenting with the filesize check and the
fact that this is our position. Then, the no timestamp/filesize change
case is a WONTFIX.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 20 09:34:42 2007