Changeset

[John A Meinel]

Moving this back to the list.

Aaron Bentley wrote:

>Hi John,
>
>John A Meinel wrote:
>
>
>>Hey Aaron, I did some work so that the output of "bzr changeset" can at
>>least be parsed back in with read_changeset.
>>
>>I was wondering if you could look at it, and see if I am creating a
>>Changeset object in the correct way.
>>
>>
>
>I don't see anything obviously wrong with what you're doing.  If you're
>worried about how you handle file creation/deletion, no I don't think
>that's a big deal.  Using ReplaceContents would give other functions a
>hope of figuring out whether the ChangesetEntry represents creation,
>deletion, or modification of text contents, but there are no such
>functions at the moment.  If you did want to use ReplaceContents, the
>transform between an add patch and the contents of the new file is
>pretty simple.
>
>
Sure. I didn't understand patch quite as well, but basically you just
strip off the first character, right? (and the end of the patch is the
first completely empty line).

>I've mentioned that I think we don't need to apply changesets, right?
>We could just have a ChangesetTree that takes a tree and a changeset as
>its arguments, and then you wouldn't need to produce a Changeset at all,
>then.  That seems to be a better fit for the model of 'diff+annotations'.
>
>
I don't really understand what you mean by not needing to "apply
changesets". There has to be some way of sending a changeset, such that
someone can update their working tree.

Are you saying that you have an object that takes the Base tree (some
sort of RevisionTree object), and then produces a different tree, which
could then be compared using something like the merge code against the
current working tree.

I suppose if you only want to work in snapshots and merges, then that
works okay. But it seems to me like you add adding 1 extra level of
work. You are generating a tree, so that merge can generate it's own
Changeset and apply it (in merge_flex).
Doesn't it make more sense to generate your own Changeset and apply it
directly?

The only other piece, though, is that Martin is requesting that we get
rid of file ids, which means that we are going to need the Base tree so
that we can figure out what all the file ids are. So far, I haven't
needed base, because I made sure to transmit everything necessary in the
changeset.

I also would like to switch from using bzrlib.diff.compare_trees into
using the bzrlib.changeset code. Is that foolish since we want the final
output to be an annotated diff? I feel like bzrlib.changeset is going to
somehow end up superior to bzrlib.diff, but they may be equivalent.

There is also the issue with automatic application. If cset.base_id ==
branch.last_patch(), you can apply the changeset and commit it, such
that you preserve the revision identities.

Obviously, right now you have the problem that you need matching
'text_id' fields in the <inventory>, but as Martin mentioned, we can
change text_id into revision_id. And update the gen_changeset code so
that it outputs whatever id only when it does not match the target
revision_id. (the first revision: entry). Or maybe just if "cur.text_id
!= base.text_id && cur.text_id != revision_id".

>But he who cuts the code gets to make the design decisions.
>
>Aaron
>
>
Naturally, but we all want to work together, right?

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