what to use to replace bzrlib.changeset?

[Aaron Bentley]

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

Jamie Wilkinson wrote:
| This one time, at band camp, Aaron Bentley wrote:
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>Jamie Wilkinson wrote:
|>| This one time, at band camp, Aaron Bentley wrote:
|>|>I suspect your use case is best handled with merge, which
|>|>compares two revisions, and applies new changes to a third.
|>
|>| The problem I had using the merge code last time is that it expected
that
|>| both the merge source and destination branches had a common ancestor
|>
|>No, that's not required.  You can get some very useful effects by
|>specifying a base that is not a common ancestor.  For example, if you
|>want to apply the changes introduced by revno 6, you can do 'bzr merge
|>- -r 5..6'.
|
|
| Are you merging revno 6 back into the same branch?  That seems... more
evil
| than the graft plugin :)

No, I was leaving out the branch spec, but ending my sentence with a
period.  You ought to be able to do that too, but there's a locking
problem at the moment.  Probably something for 0.9.  Especially good
when you have revision 10, and you want to get rid of the changes
introduced by revision 6.

| But bzr internally knows that a revno on one branch can be merged into
| another branch, because the two branches can be traced back to one parent.
| At least, that's my understanding of it.  Are you saying merge will
actually
| let you merge from one branch to another *even if* they don't share a
common
| ancestor?

There are two answers here.  The relevent one is that the default merge3
merge and the diff3 merge do not know or care anything about revisions.
~ They operate on tree snapshots, and do not care how or whether they are
related.

The other answer is that all bzr branches have a common ancestor; the
NULL revision.  So to combine two formerly-separate projects, you can do
"merge -r 0..-1 $OTHER_PROJECT".  The zero specifies the NULL revision,
and means "yes, I really do want to combine two basically unrelated
projects."

|>If you need your tree-states to vary from the original ones, then you
|>simply need to iterate through the revision history, specifying the
|>previous revision as the base for the current one, each time.
|
|
| I think that's close to analogous to what I was doing with changesets in
| graft earlier.  Thanks for the tips.

You're welcome.  Sorry about the mess.

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

iD8DBQFEDOTU0F+nu1YWqI0RAgdeAJ9Ds5xwSDOeQU0Rwdu2JevBo2jgogCcDYvg
OW7UQLNVxF9gJz/WZKNy93w=
=G+Zs
-----END PGP SIGNATURE-----