[MERGE] migrate switch command into the core

Ian Clatworthy ian.clatworthy at internode.on.net
Mon Nov 19 04:02:58 GMT 2007


John Arbash Meinel wrote:
> Aaron Bentley wrote:
>> ^^^ something wacky here; if to_branch == tree.branch, why do we need both?
> 
> I agree. Looking closely at the code, to_branch is not needed. Specifically the
> code is:
>     set_branch_location(control_dir, to_branch)
>     tree = control_dir.open_workingtree()
>     _update(tree, source_repository, to_branch)
> 
> set_branch_location() sneaks in and directly writes to '.bzr/branch/location'.
> So that when we call control_dir.open_workingtree() it is now pointing at the
> new branch location. So we shouldn't need to_branch at all.

Fixed in the patch I'll resubmit shortly.

> What I would like to see is a way to do:
> 
> base_tree = tree.basis_tree()
> 
> Which is valid for DirState trees even after having the branch pointer moved
> (and should be faster than extracting it from the repository). We would want to
> be careful, because pre-dirstate goes to the repository, and it may not be
> available in the new branch.
> 
> But it would be really nice if we could make 'bzr switch' super fast. I also
> wonder about the new "update_basis_by_delta". Merge3Merger has already had to
> do all the work to figure out the difference between the old basis_tree() and
> the new basis_tree(). And I know that 'commit' performance got a lot better
> using update_basis_by_delta. (Mostly because it doesn't have to loop over the
> whole tree to figure out set_parent_trees()).

Interesting. My preference is to put this on hold for now and land the
existing functionality before optimising.

On a semi-related topic though, I'm wondering whether the code for
update (cmd_update in builtins.py) ought to be factored out and used
instead of switch doing its own update logic. It would be useful if
switch supported -r down the track just like update ought to. By having
common code, this ought to largely fall out once update -r support
(http://bundlebuggy.aaronbentley.com/download_patch/%3C18108.46327.985869.924177@gargle.gargle.HOWL%3E)
is fully cooked, yes? Likewise, optimising one ought to optimise the
other. What do you think? Any reason not to do this?

> I'm also a little concerned about what 'bzr switch' will do in a tree with a
> pending merge. It looks safe when there are uncommitted changes (since it does
> a merge with the working tree rather than just overwriting it.) But do we leave
> the pending merge? Do we fail if there is a pending merge?
> 
> It would be nice if switch could handle a pending merge, so that after you do
> the merge you can realize... oh, I need to be on a different branch. But I'm
> always a bit leery of merging into an existing merge. So I would be willing to
> be conservative and have them revert the pending merge first.
> 
> Whichever way it goes, we should at least have a test case for it, so that our
> behavior isn't random.

Chatting with Aaron on IRC, my plan is to fail if there is a pending
merge. That is done now and will be included in the resubmitted patch soon.

Ian C.



More information about the bazaar mailing list