Merge lp:~garyvdm/bzr/bug588698-criss-cross-null-base into lp:bzr
Proposed by
Gary van der Merwe
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | John A Meinel | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 5543 | ||||
Proposed branch: | lp:~garyvdm/bzr/bug588698-criss-cross-null-base | ||||
Merge into: | lp:bzr | ||||
Diff against target: |
152 lines (+61/-7) 5 files modified
bzrlib/branchbuilder.py (+5/-1) bzrlib/merge.py (+15/-6) bzrlib/tests/test_branchbuilder.py (+15/-0) bzrlib/tests/test_merge.py (+20/-0) doc/en/release-notes/bzr-2.3.txt (+6/-0) |
||||
To merge this branch: | bzr merge lp:~garyvdm/bzr/bug588698-criss-cross-null-base | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
John A Meinel | Needs Information | ||
Review via email: mp+41047@code.launchpad.net |
Description of the change
This makes merge choose one of the lcas as the base revision when it cannot locate a unique lca, for example where there is a criss-cross merge of a new root.
It chooses the lca by taking the first lca from find_merge_
This has a drive-by fix to make BranchBuilder.
To post a comment you must log in.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/17/2010 7:44 AM, Gary van der Merwe wrote: /bugs.launchpad .net/bugs/ 588698 order(lcas) . This seems to give the most sensible for all the user tests I have run. build_snapshot accept parent_ids == ['null:']. This was done to make it easier to write a test using BranchBuilder that introduces a new root into the graph.
> Gary van der Merwe has proposed merging lp:~garyvdm/bzr/bug588698-criss-cross-null-base into lp:bzr.
>
> Requested reviews:
> bzr-core (bzr-core)
> Related bugs:
> #588698 "bzr merge" fails "Branches have no common ancestor"
> https:/
>
>
> This makes merge choose one of the lcas as the base revision when it cannot locate a unique lca, for example where there is a criss-cross merge of a new root.
>
> It chooses the lca by taking the first lca from find_merge_
>
> This has a drive-by fix to make BranchBuilder.
- - if parent_ids is not None: NULL_REVISION] :
+ if parent_ids == [revision.
^- Are we sure parent_ids is always a list? Could it be a tuple: NULL_REVISION, ).
(revision.
I think it usually is. However, you shouldn't need to pass
[NULL_REVISION] either. Just pass the empty list (I think).
+ builder. build_snapshot( 'B-id', [],
+ [('add', ('', None, 'directory', None))])
I'm not positive if that works, but it does actually match certain bits
of code better. ('null:' isn't saved to the index files, for example).
I'd have to dig a bit deeper to sort out the rest. However, this snippet
looks worrying:
- - self._is_ criss_cross = True graph.find_ merge_order(
+ sorted_lca_keys = self.revision_
+ revisions[0], lcas) NULL_REVISION:
+ if self.base_rev_id == _mod_revision.
+ self.base_rev_id = sorted_lca_keys[0]
+
graph.find_ merge_order is not a cheap operation, because it has to walk
the ancestry. Could we do it only in the 'if' block:
if self.base_rev_id == _mod_revision. NULL_REVISION: mutter( "hit the NULL_REVISION as the unique LCA." graph.find_ merge_order( revisions[ 0], base_rev_ id = sorted_lca_keys[0]
trace.
" Picking the 'first' lca as BASE")
sorted_lca_keys = self.revision_
lcas)
self.
...
+ interesting_
list(set(
^- This doesn't preserve the ordering of interesting_ revision_ ids. But
since it looks like we don't need the specific order, why not just use a
set and not cast to a list in the first place?
I see that 'sorted_lca_keys' is used again right after this point. but
is it used in all possible cases?
Anyway, the basic concept seems fine. Failing down to NULL_REVISION is
bad, picking a 'best guess' LCA seems reasonable. We may want to inform
the user that we did this, in case it would be confusing why X or Y
didn't happen. At least a mutter() helps us debug it if it is happening.
John
=:->
review: needs_information enigmail. mozdev....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://