[BUG] apply_changeset / generate_changeset use wrong base

[Aaron Bentley]

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

John A Meinel wrote:
> Aaron Bentley wrote:
> 
>>I take it back.  Using the common ancestor as the changeset base will
>>show the differences most clearly.

> I think using the common ancestor will show what I have done. While
> using the last commit will show what it will do to your tree.

No, using the common ancestor shows (roughly) what it would do to my
tree (aside from conflicts and parallel changes).  And the point of a
merge is to do to my tree what you did to yours.  So the common ancestor
should do both.

Using the last commit would show the differences between your tree and
mine, both from what you'd done, and from my changes.

> There is a case for both.
> However, once you have "bzr apply-changeset <cset>" you can just do "bzr
> diff | vim -" to see how the changes apply to your tree.
> 
> You could always use a throwaway branch to make sure you don't mess up
> the important branch.

Yeah.  Especially if apply-changeset refuses to apply on a modified tree
(by default).  I'm just thinking of what would be the best default for
mailed revisions.

Btw, I am running into all kinds of problems because
1. bzr's revision hash includes parent hashes
2. bzr upgrade doesn't upgrade all revisions
3. different trees are missing different revisions.

For example, I can't create a changeset in integration and apply it to
bzr.24.

> So did we ever work out what the new syntax was going to look like? Are
> we switching to using the semi-colon syntax?

I don't think so, but now that we can specify revisions that aren't in
the revision history, I think we can pile anything we want onto the -r
syntax.

I've switched to using common_ancestor, but now test cases are failing,
and I'm not sure what to do:

======================================================================
ERROR: test_changeset (bzrlib.plugin.bzr-changeset.testchangeset.CSetTester)
- ----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/abentley/.bzr.conf/plugins/bzr-changeset/testchangeset.py", line
419, in test_changeset
    cset = self.get_valid_cset(None, 'a at cset-0-1')
  File
"/home/abentley/.bzr.conf/plugins/bzr-changeset/testchangeset.py", line
315, in get_valid_cset
    auto_commit=auto_commit, checkout_dir=checkout_dir)
  File
"/home/abentley/.bzr.conf/plugins/bzr-changeset/testchangeset.py", line
355, in valid_apply_changeset
    auto_committed = _apply_cset(to_branch, cset, auto_commit=auto_commit)
  File
"/home/abentley/.bzr.conf/plugins/bzr-changeset/apply_changeset.py",
line 114, in _apply_cset
    base = common_ancestor(branch.last_patch(), cset_info.target, branch)
  File "/home/abentley/bzr.24/bzrlib/revision.py", line 274, in
common_ancestor
    raise bzrlib.errors.NoCommonAncestor(revision_a, revision_b)
NoCommonAncestor: Revisions have no common ancestor: None a at cset-0-1.

common_ancestor is supposed to throw an exception when two trees don't
have a common ancestor (aside from null:).  This is because it's more
likely to be a mistake than anything else.  If the user truly wants to
combine two unrelated trees, (i.e. graft one tree onto another) they can
do bzr merge -r0..-1.

I think the same applies here, so that would mean we should fix the test
cases, not the code.

What do you think?

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

iD4DBQFDObuw0F+nu1YWqI0RAvz5AJ0TVUTzHN424vzfDxJsjMA5K06AbgCY5dmA
Vv+Q57KQEq/iuoou7nFccg==
=KbQI
-----END PGP SIGNATURE-----