[BUG] apply_changeset / generate_changeset use wrong base

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> As far as I know, it does, though it might do that check a little bit
> late (after pulling in the revisions).

What's a few unused revisions between friends? :-)

>> Btw, I am running into all kinds of problems because
>> 1. bzr's revision hash includes parent hashes
>> 2. bzr upgrade doesn't upgrade all revisions
>> 3. different trees are missin,g different revisions.
>>
>> For example, I can't create a changeset in integration and apply it to
>> bzr.24.
>>
> 
> Because one has been upgraded and one hasn't? In general if one tree has
> a different hash for a revision entry than the other, that should be a
> problem to start with.

Yeah, I guess my point is it's not the kind of problem worth having,
when the only difference between two revisions is the SHA-1 hash
associated with parents (or lack thereof).

> If you look at the request, it is "get_valid_cset(None, 'a at cset-0-1')"
> So maybe it should just be changed to "get_valid_cset('null:',
> 'a at cset-0-1')"

It's not a 'null:' vs None issue, in fact I was already translating None
to 'null:'

> There needs to be some way to get the complete changeset of the entire
> history.

Sure.

>> common_ancestor is supposed to throw an exception when two trees don't 
>> have a common ancestor (aside from null:).  This is because it's more
>> likely to be a mistake than anything else.  If the user truly wants to
>> combine two unrelated trees, (i.e. graft one tree onto another) they can
>> do bzr merge -r0..-1.
>>
>> I think the same applies here, so that would mean we should fix the test
>> cases, not the code.
> 
> 
> I think you misunderstood what the test case was trying to do. They were
> related branches, in that it was a branch against 'null:'.

My feeling is that branches that only have null: in common aren't really
related.  It usually wouldn't make much sense to apply a changeset for
bzrtools to bzr, for example.  So I don't think we should do that by
default.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOjM90F+nu1YWqI0RAlAFAJ9kkITIorQPAaKjN2VqoYzuWnyjJwCdECNG
fHjnGqcj5gBEtB7EWzkiba0=
=2pw+
-----END PGP SIGNATURE-----