[BUG] apply_changeset / generate_changeset use wrong base

[John A Meinel]

Aaron Bentley wrote:
> 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? :-)

Obviously, I think we generally don't worry about it.

> 
> 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).

I've conceded that we don't have to include the sha of the parents in 
the sha of this entry. But I would still like to include the sha when 
present. It is at least a little bit of a check that the parent is who 
you think it is.

> 
> 
>>>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.

So how would you do this, other than a 'null:' => last_patch() changeset?

> 
> 
>>>>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.

But what about publishing your archive as a changeset. Somehow you have 
to get started. I agree it doesn't make much sense to merge bzrtools 
into bzr (though I would argue that it would be nice to be able to merge 
distinct branches together in case the project itself merges, I've had 
to do it manually for some things.)

What makes more sense, though, is being able to apply_changeset() my 
tree into a blank branch. If we are accepting the idea that merge and 
branch can be supplanted by changesets (in the case that someone is 
unable to publish their branches), then there needs to be a way to 
bootstrap that process.

I'm not asking to be able to merge two branches that only share 'null:' 
(though I'm asking that separately, perhaps with a flag to not do it by 
accident), I'm asking for being able to recreate the first commit.

John
=:->


> 
> Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050928/1a59be99/attachment.pgp