-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Burba wrote:
> On Thu, May 8, 2008 at 11:50 AM, Kamesh Jayachandran <kamesh_at_collab.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> >
>> > Hi Kamesh,
>> >
>> > Shouldn't r2 be gone entirely from any mergeinfo now that issue #3157
>> > is fixed? It is from the natural history of 'H_COPY' so should never
>> > appear explicitly.
>>
>> No.
>>
>> Prior to 'merge harvest' H_COPY/nu has a mergeinfo of '/A/D/H/nu:2,7',
>> out of which '/A/D/H/nu:2' is *bogus* as '/A/D/H/nu itself has been
>> created r3 and r5 only.
>>
>> > Also, why should 'H_COPY/nu' have any explicit mergeinfo on it at the
>> > end of this test? The final merge of the test a cherry harvest all
>> > eligible revisions from 'A/D/H' to 'H_COPY' so no subtree of 'H_COPY'
>> > should have any explicit mergeinfo right?
>>
>> As 'H_COPY/nu' has the explicit bogus mergeinfo of '/A/D/H/nu:2' on it
>> it does not elide to H_COPY as H_COPY had no 'nu' at r2.
>
> That is what I am saying! '/A/D/H/nu:2' is bogus, it shouldn't exist,
> why is the test written to expect it? I'm totally confused.
It is written to cover the case when 'merge_src_subtree_rel_path_at_REV2'
does not exist we should handle it for this fix. This bogus merge is one
case of such a non-existent 'merge_src_subtree_rel_path_at_REV2'.
r31090 is anonther case of non-existent merge_src_subtree_rel_path_at_REV2'
as explained in other email.
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIIyUy3WHvyO0YTCwRArhHAJ0formWMEvQ1OmDJ72dEJkNlz0wvwCeItCT
NI1gkws28YKiTGyfXGVS5bc=
=OfWc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-08 18:08:00 CEST