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

Re: Nasty double-replace copy-on-update bug

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2007-10-19 18:58:02 CEST

"Ben Collins-Sussman" <sussman@red-bean.com> writes:

> Huh? The whole bug here is that alpha isn't fetched via RA, it's
> being copied from an existing wc file.
> Let me walk over update-test #40 again; I think I don't understand
> where you've gdb'd.

There are *two* sets of copied-from date. The checkout attempts to
construct file alpha@3, which is copied from gamma@1 and subsequently
modified, and aardvark@3, which is copied from alpha@1 and
subsequently modified. However while constructing alpha@3 it
temporarily constructs something it calls alpha@1, by copying from
gamma@1 including the committed-rev, which it will later convert into
alpha@3. Note that the thing called alpha@1 in the wc isn't the same
as alpha@1 in the repository, it's a copy of gamma@1. When
constructing aardvark@3 the code finds the temporary alpha@1 and uses
it, which is where it all falls down.

I quit out of gdb just after running the log file that created

I think you could make the test pass by avoiding copying the
committed-rev, so that the temporary became alpha@-1, and by making
locate_copyfrom recognise that -1 is not valid committed-rev. Then
when attempting to construct aardvark@3 the code would retrieve
alpha@1 from the repository. Although the test might pass it would
*not* fix the problem that the working copy is temporarily in an
invalid state.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 18:58:36 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.