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

Re: [Issue 2746] New - update overwrites w/o warning local modification if local timestamp did not change

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-03-20 02:19:46 CET

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 20 02:20:05 2007

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

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