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

[Aaron Bentley]

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

John A Meinel wrote:
> 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



Yeah, that would work, I think.  This might be even simpler:

For generation:
if guess_text_id(file_id) != change.final_text_id:
    print change.final_text_id

For application:
if text_id is None:
    text_id = guess_text_id(file_id)

That means as long as the transmitter and receiver have the same
guess_text_id, it will all work properly.  It should handle legacy data
(i.e. what we have now) just fine, too.

Then guess_text_id can do the if_should_update_text_id stuff.

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

With the approach I suggested, SHA1 hashes can be treated as unguessable
text-ids.  Or guessable ones, I suppose.

> I think it is a decent validation check to send the 'inventory_sha1' in
> the changeset.

I think it would make sense to move revfiles to having fileid/revisionid
text_ids, instead of accessing by SHA1.  I believe that sending the SHA1
in the changeset would, in general, be considered 'too much gunk'.

> It also means that you could validate part of a changeset without having
> the "base" tree available. Which again seems worthwhile.

You'd only be able to validate new files, which doesn't seem like it
outweighs the 'too much gunk' issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCwtuS0F+nu1YWqI0RAhCuAJ0cwjU8orHmJ0c32BlTLl2esbVaDwCfRXEb
uaIwmHVIzcDpcCkM0+X2WrQ=
=810A
-----END PGP SIGNATURE-----