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

On 2007-03-19 20:19:46 -0500, Ben Collins-Sussman 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.

This sucks because such tools are common under Unix. "mv" is one of
them. And no, such tools are NOT fixed.

BTW, has "svn export" been fixed?

Also, I don't see the point of not supporting such tools (possibly
in an optional way).

> 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,

No, this doesn't fix the problem.

> 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

Why would looking at ctime be slower?

Note: the only problem with ctime is with chmod, but in general,
users don't do a chmod on their Subversion files, and when they
do it, it should be rare.

> universe just to prevent dataloss for the .01% of tools that blatantly
> flaunt convention.

This is only *your* point of view.

> 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. :-)

I'm not asking to choose between performance and support for some
(non always broken) tools. Using ctime (possibly in addition to
mtime[*]) should be fine.

[*] that would take a few additonal processor cycles per file, so that
the user won't see the speed difference.

-- 
Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org