On 3/24/07, Mark Phippard <markphip@gmail.com> wrote:
> 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.
While I still think this is all true, I don't feel we're all talking
about the same thing:
I wasn't talking about making Subversion in general slower and more
exact by doing a full file compare: status, commit and other wc
operations would still be as slow/fast as they are today. What I *was*
talking about, is changing /update/ and /switch/ to be really really
sure that they don't overwrite local changes. This would indeed make
updates and switches slower, because when they would be about to
overwrite a file with an 'unchanged' status, they'd still need to read
the entire wc file to test for 'not changed'.
The thing here is that this may not be very appealing at first, but as
soon as you realise that 'update/switch' only change fractions of a
working copy in the normal use-case, the performance impact will be
significant, but far less than for operations like /status/.
I just wanted to mention this, because we *are* overwriting files and
thereby removing the data which exists at that location.
There is another solution though: if we were to rename the original
file - like CVS does - and then put the updated content in its place,
we weren't overwriting (ie loosing) data at all, just moving 'possibly
changed' files around without nicely merging them...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 24 22:30:02 2007