[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: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-03-21 15:50:07 CET

On 3/21/07, Vincent Lefevre <vincent+svn@vinc17.org> wrote:
> 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.

But certainly, you won't *always* replace a checked out file with one
of *exactly* the same size, right? We do size-caching now (it will be
available in 1.5), so that should reduce chances of running into this
problem.

> BTW, has "svn export" been fixed?
>
> Also, I don't see the point of not supporting such tools (possibly
> in an optional way).

I'm not sure this is true (I'm at work and can't test the behaviour
right now), but possibly the --force parameter to commit will check
the entire file before committing?

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

It doesn't fix it, but it does reduce chances even further than the
current chance at running into it.

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

It isn't.

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

ctime is not reliable in the face of networking filesystems.

> > universe just to prevent dataloss for the .01% of tools that blatantly
> > flaunt convention.
>
> This is only *your* point of view.

It is? If this were truely one of our biggest problems, then why
aren't our lists flooded with bugreports/enhancement requests?

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

Umm, well, only when not operating on network filesystems, but
especially working copies are supposed to work on network shares.

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

But the fallback is a full file compare, meaning a *lot* of extra
i/o... (Surely a measurable difference).

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 21 15:50:48 2007

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