[RFC] Separating last-revision from parents

[Robert Collins]

On Thu, 2007-02-01 at 22:49 -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Henry Ludemann wrote:
> > Suggest pull when asked to merge into an empty branch.
> > 
> > Merging to an empty tree fails (see bug 82555 for testcase and attempted
> > fixes).
> 
> In that bug, Henry suggests separating last-revision and pending-merges
> back to the way they used to be.
> 
> I've been thinking about a related issue lately, and I think separation
> is good, but we should have last_revision, and pending_parents.
> 
> When we do an update, we swap the left and right parents, so that the
> resulting revision is a merge of the local branch into the master
> branch, not a merge of the master branch into the local branch.
> 
> But this make 'revert' a highly dangerous command, because it will throw
> away all your local *committed* changes.
> 
> It also make status and diff behave strangely, because it changes the
> basis of comparison.
> 
> And it also isn't so hot for doing multiple iterations of update,
> resolve conflicts, update, which is probably the most desirable workflow
> when you have two sync problems (tree out of date with local branch
> *and* local branch out of date with master branch).
> 
> So one option would be a 'swap-parents' flag.  But that's rather
> arbitrary.  If there's more than two parents, which one should become
> the new last-revision?
> 
> Why not just say "parents" is about the parents of the revision that
> will be created, and have a separate value for last-revision?
> 
> That would mean swapping parents wouldn't change the basis revision,
> which would fix status, diff and revert.  Update would be a more
> tractable problem, too.

I think I'll tackle update tomorrow, your sketch of how it should look
back last year sounded good to me and is straight forward to implement.

The current behaviour of update and revert is in my mind 'correct' -
that is, we can probably improve it, buts its doing what I intended.

I wanted the following to hold true for any tree:
 'bzr update && bzr revert && bzr info -> no missing revisions, no local
edits, no new local commits. 
   That is, for a regular branch, it gets you to the tip, for a
lightweight checkout, it gets you to the tip of the pointed-at-branch,
and for a heavyweight branch it gets the local branch reset to the
master.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070204/9807f4e1/attachment.pgp