[PLUGIN] bzr changeset, time to pull again

[John A Meinel]

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

Now the 'bzr changeset' function creates a text with fewer annotations,
only including entries which cannot be guessed. Basically, it assumes
that the target will have the 'base' revision available. So entries that
have either changed in an obvious fashion, or that have not changed at
all are not included.

Attached is a representative sample. I don't think there is much more
that we can trim out of this.

And to make things extra tasty, I have validated that 'bzr cset | bzr
verify-changeset' does indeed generate the same revision XML.

Now, I can't say that the same will be true for older revisions which
are missing things like the timezone header. But that is because they
don't conform to the current standard. One could argue that they should
be upgraded anyway.

I should have enough information that the inventory XML can also be
reproduced, but that has not been tested.

I haven't had a chance to create test cases for everything, though I did
run it through it's paces on my own, and fixed a couple of small bugs
(where base was None, etc.)

Anyway, feel free to pound on it, and give me some feedback.

I'm also including the text of a rollup changeset. It is for a trivial
set of files, but it shows pretty much what you need.

The only redundant information that I know of, is that if a revision is
a parent in a rollup changeset, it's id and sha hash are given twice.
Once as a reference, and again when defining the entry. I don't really
want to get rid of that redundancy, but technically you could. (at least
not print the sha hash if you have given it, but which place would you
prefer?)

The other thing which Aaron provided was a ChangesetTree complete with a
whole bunch of unit tests.
So the basic process is that bzr apply-changeset will create an
in-memory "ChangesetTree" which can then be used by the merge code.

There are a whole lot of things left to be done. Such as the following:

   1. There needs to be a way to specify BASE, TARGET, and START
      revisions. Currently base and target can be given with the -r
      flag, and it is assumed that start = base+1 in the current
      revision history. We need to be able to set base to be some other
      tree so that we can generate the changeset which lets us easily
      merge this tree into other tree. I feel that if you supply a BASE,
      TARGET defaults to the current revision of the current branch, and
      START defaults to the merge-base between the two trees. Notation
      would be something like:
      bzr cset [BASE [TARGET]
   2. The code *needs* unit tests. Simple tests start with just creating
      an empty branch, and adding a file to it one at a time, and
      validating that the patches can be applied on a second tree, and
      file contents stay the same, etc. It's a pretty big undertaking.
   3. verify-changeset should use the ChangesetTree to build up an
      inventory, which it then can validate the inventory SHA hash.
   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.
   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.
      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.
   6. ?????
   7. Profit?

Sorry, it is 3am and I *really* need to go to bed.
I'm sure there is more, but this might give someone who wants to play
around a fun project to work on. I think 1,2 and 3 shouldn't be very
hard. 4 and 5 are probably more for Aaron Bentley, and 7 is for everyone.

Good night,
John
=:->

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rev-53.cset
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20050702/8729c798/attachment.diff 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rev-rollup.cset
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20050702/8729c798/attachment-0001.diff 
-------------- 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/8729c798/attachment.pgp