Hi Cristian. I committed that merge test you are helping me write, in r1342283. It is merge_reintegrate_tests.py 20, and it performs a reintegrate merge after renaming the source branch:
# A -1-----3-4-5-6----------------------9-------- # \ \ / reintegrate # A_COPY 2--------------7-------- / # sync \ / # RENAMED rename 8---------------- As I mentioned -- and I am now repeating on the dev list in order to move the discussion here -- the reason I started to write this test in the first place is because I've been studying the merge implementation and I think there are places in the code where it may not follow the history of a branch properly, so I suspect there may be some cases involving renames in which it is broken, but I haven't worked out exactly what cases. So I want to exercise the merge code in this way and see if we can find these kinds of bugs. I am thinking mainly of cases where the code might look at the right revision number but the wrong path -- for example, looking at the diagram above, it might look for the path 'RENAMED/...' in revision 7. The more complex the merge is, the more more likely we are to hit any such bugs -- if there are any, of course. Also, I want to run this scenario both with the old merge code and with the new 'symmetric' merge code, and see if they both work. (To run it with the new 'symmetric' merge code, at the moment I do this by applying the attached patch 'use-symmetric-merge-1.patch'.) I have put three "to do" notes in the test: # TODO: Make some changes between the sync/rename/reintegrate steps so # the reintegrate merge actually has to do something. # TODO: Rename the other branch as well. (Because we know that the code is not completely symmetric -- in fact, at the moment, it's still very asymmetric.) # TODO: Check the result more carefully than merely that it completed. You were asking whether we should create a separate test for the case where the other branch has the rename. We could do, but we are looking for one kind of bug, one kind of correct behaviour, and so I think it best to put all the renames into the same test. In fact, perhaps we should make two renames in each branch, because I can just about imagine ways in which the code might behave correctly with one rename but wrongly with two successive renames. (In contrast, when we write a regression test for a specific bug that we've already found, it is best if there is one regression test for each bug.) - Julian
use-symmetric-merge-1.patch
Description: Binary data
