On 3/21/07, Vincent Lefevre <vincent+svn@vinc17.org> wrote:
> On 2007-03-21 15:50:07 +0100, Erik Huelsmann wrote:
> > On 3/21/07, Vincent Lefevre <vincent+svn@vinc17.org> wrote:
> > >On 2007-03-19 20:19:46 -0500, Ben Collins-Sussman wrote:
> > >> 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.
>
> Not always, of course. The problem would be rare. But losing data
> (and not knowning immediately that data are lost), even if this is
> rare, is very bad.
>
> > >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?
>
> There could be such an option[*], but it would make various operations
> very slow. Remember that the user doesn't necessarily know in advance
> if such an option would be needed.
>
> [*] It could be useful to do a "svn --force st" before a "rm -rf" of
> the working copy.
>
> > >> 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.
>
> This is the first time I've heard about that. I know that atime is
> not reliable (for efficiency reasons), but what are the problems
> with ctime?
It's not indicative of anything that happened as a result of user
action: it may change due to processes run by an administrator too.
That means that where mtime and file size changes are normally caused
by things the user did, ctime changes don't necessarily -probably
generally even- indicate that. [*]
> >
> > But the fallback is a full file compare, meaning a *lot* of extra
> > i/o... (Surely a measurable difference).
>
> I repeat that a full file compare is not a solution either, and I'm
> waiting for more information about ctime.
Ok. I hope I provided the information you're looking for in this post.
bye,
Erik.
[*] As indicated in
http://groups.google.nl/group/gnu.misc.discuss/browse_thread/thread/6e8fa32ef66f5fa6/24c55a64b4e6c7b5?lnk=st&q=filesystem+ctime+problem&rnum=31&hl=nl#24c55a64b4e6c7b5
backup software or other processes which restore atimes can and will
cause ctime changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 21 18:49:05 2007