"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
alpha@1.
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