[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: *Update* correctness vs speed (was: [Issue 2746] New - update overwrites w/o warning local modification if local timestamp did not change)

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2007-03-24 23:12:31 CET

On 3/24/07, Erik Huelsmann <ehuels@gmail.com> wrote:
> 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*

No, they'd have to do full compares as well - otherwise, how would you
know the file has changed? If I did the 'mv' op from ghudson, under
this scenario, I'd then expect that Subversion needs to pick up on
this if I tried to commit or run status. If not, it wouldn't detect
the file has changed. So, no, if we're going to do this, it has to be
done for *all* WC operations. Either Subversion is consistent about
this behavior, or we say, 'sorry, we won't support it' - but the
half-hearted solution doesn't seem right.

> 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 think the majority of cases is that files haven't changed in a WC,
so we're going to be forcing comparisons on every updated files. This
would be death on large WCs. I'd like to see performance impact of
having to recompute checksums every time a file remotely changed - my
expectation is that it won't be a pretty sight.

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

When does CVS preserve the original file? It never did, AFAIK. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 24 23:12:44 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.