[MERGE] support updating lightweight checkouts of readonly branches

[Aaron Bentley]

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

Robert Collins wrote:
> On Wed, 2006-10-18 at 00:24 -0400, Aaron Bentley wrote:
>> Well, what I'm ultimately expecting is
>>
>> #pseudocode
>> conflicts = tree.tree_update()
>> if conflicts != []:
>>     print_conflicts(conflicts)
>>     return 1
>>
>> if tree.branch.get_master_branch():
>>     branch.update()
>>     conflicts = tree.tree_update()
>>     if conflicts != []:
>>         print_conflicts(conflicts)
>>         return 1
> 
> Isn't this the wrong order ? In that you'll need to do
> tree.tree_update
> branch.update
> tree.tree_update
> 
> to fully update ?

There are two update steps, and they are separable.  As we've previously
discussed, it's desirable to stop after the first merge, if it produces
conflicts.

> And, as the branch update step adds parents to be a pending merge, and
> needs to change the working tree to match, I think [also pseudo code],
> that something like
> conflicts = tree.update() 

I was planning to continue to support the WorkingTree.update method, but
it doesn't tell you whether the first or second step conflicted, which
is information you need to pass to the user.  So I see it as an
advantage for cmd_builtins.run to be aware of both steps.

> should be all you need, with the inside of tree.update doing:
> if self.branch.master.tip != self.branch.tip:
>     # pivot and merge 
> if no_conflicts_so_far:
>     # update the tree against the branch
> 
> Which also has the property of splitting the two different forms of
> update, but wont require three different tree operations to fully update
> in the general case.

Are you counting branch.update as a tree operation?

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

iD8DBQFFNhcJ0F+nu1YWqI0RAi8cAJ415l9VnRtuONa86Y9aGUxl4UmOBgCfTnEP
5ccdcLgRtbxIUv5k7oZy0SQ=
=qUNt
-----END PGP SIGNATURE-----