Changeset

[Aaron Bentley]

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

John A Meinel wrote:
> Moving this back to the list.
> 
> 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).

Yeah.  Or you can just call bzrlib.patch.patch()

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

You can only apply a changeset to the working tree if the working tree
happens to be identical to the base revision for the changeset.  I was
thinking of always merging, which covers the cases where

1. the working tree is identical to a descendant of the changeset base
(fairly common)

2. the working tree has local changes (not sure if this one matters)

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

Yes, that was the idea.

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

Since you can't do that when the working directory isn't identical to
the changeset base, you'll need to do merges some of the time.  So you
might as well do them all the time.

Actually, I think a good process would be:
1. generate ChangesetTree
2. store all data for the changeset revision in the branch stores
3. do a merge, using either the RevisionTree or the ChangesetTree for
the changeset revision.
4. update branch metadata (either revision history or merge-parents,
depending on whether the current branch revision was an ancestor of the
changeset revision).

One neat thing about ChangesetTrees is that in theory, using one doesn't
require any filesystem access.

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

Yeah, so a ChangesetTree can operate primarily in terms of file paths,
which is an advantage when the changesets themselves lack file IDs for
most files.  It's not the only way, but it does seem like a simple way.

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

Currently, bzrlib.diff is faster.  I think bzrlib.changeset gives you
more detailed data, but has external dependencies (/usr/bin/diff).

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

I think it's not the changeset base that matters, it's whether the
current branch revision is an (possibly indirect) ancestor of the
changeset being applied.

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

> Naturally, but we all want to work together, right?

Sure.  I didn't want to give the impression I was being bossy.  They're
meant as suggestions, not orders, and I don't have the right to give
orders, anyway.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCwtdT0F+nu1YWqI0RArI6AJ4m/0PErXT6tWemlNxF+N7B1uBSfQCfYcyj
L7x6t//n8GFuJmyAWzZqR+Y=
=d1Ep
-----END PGP SIGNATURE-----