[PLUGIN] bzr changeset now support rollup changesets (and bzr send-changeset)

[John A Meinel]

Aaron Bentley wrote:
...

>
> This makes store ids computable in most cases, but when an ID is
> introduced due to a merge, it will not be computable, I think.  So
> changesets should be able to specify the revision-id when it is not the
> target revision for the changeset.
>
Would this work (psuedocode):

for change in changes:
    # renames don't change the id, but any text difference does
    if should_update_text_id(change):
       if change.final_text_id != target_revision_id:
          print change.final_text_id
    else:
       if change.base_text_id != change.final_text_id:
          print change.final_text_id

That way if you have a rollup changeset, you can print out the "text_id"
as the intermediate value, but otherwise it is assumed to be either
unchanged, or equal to the new revision id.
The trick is to make sure "should_update_text_id" is properly defined.
What actions update the "text_id".

I'm still not sure how to handle the case of revfiles. Right now things
are looked up by their sha hash. So you have to apply the patch, and
then hash the result before you can verify the final values.

I think it is a decent validation check to send the 'inventory_sha1' in
the changeset. So that you can generate the revision xml directly,
validate the sha checksums and signatures, before you start parsing all
of the patches themselves and regenerating the inventory so that you can
validate everything.
It also means that you could validate part of a changeset without having
the "base" tree available. Which again seems worthwhile.

> Aaron

John
=:->

-------------- 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/20050629/e2d92836/attachment.pgp