[BUG] apply_changeset / generate_changeset use wrong base
John A Meinel
john at arbash-meinel.com
Wed Sep 28 16:29:33 BST 2005
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
More information about the bazaar
mailing list