On 3/24/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> 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.
Well, one could argue that status won't ever cause dataloss when not
being exact, whereas update will. I don't call that half-harted, I'd
call it 'thorough when required, fast when possible'.
> > 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
I tried to find it in the manual (I thought I had seen behaviour along
the lines in the past), but I'm apparently mistaken.
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 23:48:03 2007