[PLUGIN] bzr changeset, time to pull again

[John A Meinel]

John A Meinel wrote:

> Well, I've updated the bzr changeset plugin again, with some help from
> Aaron Bentley.

...

>   3. verify-changeset should use the ChangesetTree to build up an
>      inventory, which it then can validate the inventory SHA hash.

...
If you pull again (revno=65) you will find that I am now able to
validate the Inventory XML as well as the Revision XML.
In fact, I've added all kinds of validation code into the
ChangesetReader class. It now checks to make sure all Revision entries
validate in their XML form, before it actually parses the changeset (it
reads it and splits it into chunks, but doesn't actually handle the
contents).
And then once it has parsed the contents, it generates an Inventory
object, and validates it's XML.

So the current code is indeed able to build up a set of differences,
pipe them out as a changeset, read it back in, and have all of the sha1
hashes match. Pretty cool. You have to have BASE, but that was a design
requirement anyway.

>   4. I think the data stored in ChangesetTree should be merged with the
>      information in ChangesetInfo. Specifically, right now none of the
>      merge objects keep track of any history information.

This sort of thing still needs to be done. I think it can clean up the
code. But first, ChangesetTree should probably inherit from Tree, so
that it has an inventory property.
Also, why is it that Tree objects have a id2path function, but not
path2id function? The id2path just requests the underlying inventory to
do the work, and I assume that path2id would do the same.
Though in both cases, why doesn't the higher level code just ask the
inventory to do it?

>   5. We need some routines which read the changeset, and then check
>      that the revisions hashes validate. (In the future we could then
>      verify a gpg signature). Then it goes on to build the inventory,
>      and makes sure that it validates. Then it can actually use the
>      ChangesetTree and merge it against the working tree. I'm not sure
>      whether this should be before or after merging, but at some point
>      it should add the revision XML and inventory XML that it figured
>      out into the appropriate stores, along with the new text-store
>      entries.

As I mentioned, this portion is done, and I have proved to myself that
it actually works.
It doesn't create any entries in any stores. I don't know whether it is
better to create a temporary directory, and put a pretend branch in
there. Create all of the actual entries, and then have the merge code do
a merge against the temp dir. For now, I've been trying to work in
memory, so as to not write things to the filesystem.

>      This is where I think we should actually improve the
>      ChangesetTree, so that merge will do the pull of revision entries.
>      Perhaps we should change it to a ChangesetBranch, and merge should
>      work on branches rather than trees. Because trees don't have
>      stores, but branches do.

This is a general issue with the merge code, so I don't know how we want
to handle it. Because a merge creates an extra 'parent' entry, we should
probably pull at least the Revision XML into the local store. And
probably inside the merge code should be the one doing the pulling.
Right now the 'bzr pull' code uses Branch.update_revisions(), which
doesn't help a merge.

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/20050702/b4c30a58/attachment.pgp