[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-03-24 19:52:32 CET

On 3/24/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
>
> On 3/23/07, Greg Hudson <ghudson@mit.edu> wrote:
> > There does seem to be a real issue here:
> >
> > svn update
> > mv file1 file2 # file1 has same size and mtime as file2
> > svn rm file1
> > svn st # file2 appears unchanged
> > svn update # Smashes file2
> >
> > It may be an uncommon case, but there's no broken tool involved, and
> > mv's behavior isn't going to change.
>
> But, mv's behavior with respect to ctime isn't consistent across
> platforms or file systems. I just tried FreeBSD, Darwin, Solaris, and
> Linux. FreeBSD and Darwin don't alter ctime on mv while Solaris and
> Linux do. So, depending upon ctime telling you anything is a red
> herring doomed to failure on a sizable number of Unix platforms.

I would also add that if we did add ctime checking, then OK, on some OS's in
some fairly rare situation we would work better, But, since ctime can be
updated to the current time by many fairly common operations, we will
actually be making the product much slower, and therefore worse, for likely
a larger percentage of users. All without adding any benefits to those
users since the ctime update will be bogus for Subversion purposes and just
force the product in to performing unnecessary full file compares.

We can't save the world here. Hence, I believe our current status in
> trunk is sufficient. -- justin

Agreed. The additional check of size added to trunk should help with the
more common scenarios.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Sat Mar 24 19:52:48 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.