Fossil SCM

Improved robustness of the merge algorithm when merging long-running branches with many name changes.

drh 2021-04-20 14:16 trunk

Commit dc850c9b3b2d7e9e49413cb1a3759ad73faec86db552e4297809d8dd927abca6

Parent 8913402d1026017…

1 file changed +8 -4

M src/merge.c

+8 -4

		--- src/merge.c
		+++ src/merge.c
		@@ -598,10 +598,14 @@
598	598	** Compute name changes from N to V, P, and M
599	599	*/
600	600	add_renames("fn", vid, nid, 0, debugFlag ? "N->V" : 0);
601	601	add_renames("fnp", pid, nid, 0, debugFlag ? "N->P" : 0);
602	602	add_renames("fnm", mid, nid, backoutFlag, debugFlag ? "N->M" : 0);
	603	+ if( debugFlag ){
	604	+ fossil_print("****** FV after name change search *****\n");
	605	+ debug_fv_dump(1);
	606	+ }
603	607	if( nid!=pid ){
604	608	/* See forum thread https://fossil-scm.org/forum/forumpost/549700437b
605	609	**
606	610	** If a filename changes between nid and one of the other check-ins
607	611	** pid, vid, or mid, then it might not have changed for all of them.
		@@ -615,33 +619,33 @@
615	619	** The Fossil merge algorithm breaks down in those cases. It will need
616	620	** to be completely rewritten to handle such complex cases. Such cases
617	621	** appear to be rare, and also confusing to humans.
618	622	*/
619	623	db_multi_exec(
620		- "UPDATE fv SET fn=vfile.pathname FROM vfile"
	624	+ "UPDATE OR IGNORE fv SET fn=vfile.pathname FROM vfile"
621	625	" WHERE fn IS NULL"
622	626	" AND vfile.pathname IN (fv.fnm,fv.fnp,fv.fnn)"
623	627	" AND vfile.vid=%d;",
624	628	vid
625	629	);
626	630	db_multi_exec(
627		- "UPDATE fv SET fnp=vfile.pathname FROM vfile"
	631	+ "UPDATE OR IGNORE fv SET fnp=vfile.pathname FROM vfile"
628	632	" WHERE fnp IS NULL"
629	633	" AND vfile.pathname IN (fv.fn,fv.fnm,fv.fnn)"
630	634	" AND vfile.vid=%d;",
631	635	pid
632	636	);
633	637	db_multi_exec(
634		- "UPDATE fv SET fnm=vfile.pathname FROM vfile"
	638	+ "UPDATE OR IGNORE fv SET fnm=vfile.pathname FROM vfile"
635	639	" WHERE fnm IS NULL"
636	640	" AND vfile.pathname IN (fv.fn,fv.fnp,fv.fnn)"
637	641	" AND vfile.vid=%d;",
638	642	mid
639	643	);
640	644	}
641	645	if( debugFlag ){
642		- fossil_print("****** FV after name change search *****\n");
	646	+ fossil_print("****** FV after name change fill-in *****\n");
643	647	debug_fv_dump(1);
644	648	}
645	649
646	650	/*
647	651	** Add files found in V
648	652

	--- src/merge.c
	+++ src/merge.c
	@@ -598,10 +598,14 @@
598	** Compute name changes from N to V, P, and M
599	*/
600	add_renames("fn", vid, nid, 0, debugFlag ? "N->V" : 0);
601	add_renames("fnp", pid, nid, 0, debugFlag ? "N->P" : 0);
602	add_renames("fnm", mid, nid, backoutFlag, debugFlag ? "N->M" : 0);




603	if( nid!=pid ){
604	/* See forum thread https://fossil-scm.org/forum/forumpost/549700437b
605	**
606	** If a filename changes between nid and one of the other check-ins
607	** pid, vid, or mid, then it might not have changed for all of them.
	@@ -615,33 +619,33 @@
615	** The Fossil merge algorithm breaks down in those cases. It will need
616	** to be completely rewritten to handle such complex cases. Such cases
617	** appear to be rare, and also confusing to humans.
618	*/
619	db_multi_exec(
620	"UPDATE fv SET fn=vfile.pathname FROM vfile"
621	" WHERE fn IS NULL"
622	" AND vfile.pathname IN (fv.fnm,fv.fnp,fv.fnn)"
623	" AND vfile.vid=%d;",
624	vid
625	);
626	db_multi_exec(
627	"UPDATE fv SET fnp=vfile.pathname FROM vfile"
628	" WHERE fnp IS NULL"
629	" AND vfile.pathname IN (fv.fn,fv.fnm,fv.fnn)"
630	" AND vfile.vid=%d;",
631	pid
632	);
633	db_multi_exec(
634	"UPDATE fv SET fnm=vfile.pathname FROM vfile"
635	" WHERE fnm IS NULL"
636	" AND vfile.pathname IN (fv.fn,fv.fnp,fv.fnn)"
637	" AND vfile.vid=%d;",
638	mid
639	);
640	}
641	if( debugFlag ){
642	fossil_print("****** FV after name change search *****\n");
643	debug_fv_dump(1);
644	}
645
646	/*
647	** Add files found in V
648

	--- src/merge.c
	+++ src/merge.c
	@@ -598,10 +598,14 @@
598	** Compute name changes from N to V, P, and M
599	*/
600	add_renames("fn", vid, nid, 0, debugFlag ? "N->V" : 0);
601	add_renames("fnp", pid, nid, 0, debugFlag ? "N->P" : 0);
602	add_renames("fnm", mid, nid, backoutFlag, debugFlag ? "N->M" : 0);
603	if( debugFlag ){
604	fossil_print("****** FV after name change search *****\n");
605	debug_fv_dump(1);
606	}
607	if( nid!=pid ){
608	/* See forum thread https://fossil-scm.org/forum/forumpost/549700437b
609	**
610	** If a filename changes between nid and one of the other check-ins
611	** pid, vid, or mid, then it might not have changed for all of them.
	@@ -615,33 +619,33 @@
619	** The Fossil merge algorithm breaks down in those cases. It will need
620	** to be completely rewritten to handle such complex cases. Such cases
621	** appear to be rare, and also confusing to humans.
622	*/
623	db_multi_exec(
624	"UPDATE OR IGNORE fv SET fn=vfile.pathname FROM vfile"
625	" WHERE fn IS NULL"
626	" AND vfile.pathname IN (fv.fnm,fv.fnp,fv.fnn)"
627	" AND vfile.vid=%d;",
628	vid
629	);
630	db_multi_exec(
631	"UPDATE OR IGNORE fv SET fnp=vfile.pathname FROM vfile"
632	" WHERE fnp IS NULL"
633	" AND vfile.pathname IN (fv.fn,fv.fnm,fv.fnn)"
634	" AND vfile.vid=%d;",
635	pid
636	);
637	db_multi_exec(
638	"UPDATE OR IGNORE fv SET fnm=vfile.pathname FROM vfile"
639	" WHERE fnm IS NULL"
640	" AND vfile.pathname IN (fv.fn,fv.fnp,fv.fnn)"
641	" AND vfile.vid=%d;",
642	mid
643	);
644	}
645	if( debugFlag ){
646	fossil_print("****** FV after name change fill-in *****\n");
647	debug_fv_dump(1);
648	}
649
650	/*
651	** Add files found in V
652

Fossil SCM

Keyboard Shortcuts