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