evolve: refactor content-divergence resolution logic > What is the case we are looking at? This is about refactoring the part of content-div resolution logic where it decides which cset should be relocated and where. > What is a "topologicial common ancestors" vs a "greatest common ancestors"? `tca` is an ancestor which we can decide/find by looking at the at graph visually for e.g ``` c3(*) c4(*) | | c2(x) c1(x) c5 | / \ | / c0 ``` (c5 is the successor of c2 and c1) now here, `tca` of c3 and c4 is: c0 `gca` of c3 and c4 is: c5 > What is the new top-level logic/behavior that makes it better? The old code had some unnecessary edge cases just because we were using `gca`, since it can point to a revision that is not a topological ancestor. For e.g see b779b40f996e Eventually, the code around this was getting messy unnecessarily. So I looked into it and found a simple and more robust approach. And in new code, it is simple and straightforward (and easy to understand), where we handle the following 4 cases when solving content-div: 1) when both are on the same parent => (no need to do anything special, and simply proceed) 2) both are on the different parent but a) `tca` is the parent of one of them or b) there is no non-obsolete revision between `tca` and one of the divergent cset. => (relocate one to the other side and proceed) 3) both are on different parents and `tca` is not the parent of any of them and there is at least one non-obsolete cset between tca and both the divergent cset i.e (tca::div1) and (tca::div2) both the ranges have at least one non-obs revision. => (this is the case which we don't handle yet, but the solution would be to prompt the user to choose an evolve destination.) 4) both are in the parent-child relation => (both are merged and new cset will be based on the successor of `tca`) Changes in test-evolve-issue5958.t demonstrate that new code also covered case4 because in a resolution of "two divergent csets with parent-child relation" there should be one cset as a result and no orphan revs (as you can see there was an orphan before this patch).

VERSION=$(shell python setup.py --version)

PYTHON=python

all: help

deb-prepare:
	python setup.py sdist --dist-dir ..
	mv -f ../hg-evolve-$(VERSION).tar.gz ../mercurial-evolve_$(VERSION).orig.tar.gz
	tar xf ../mercurial-evolve_$(VERSION).orig.tar.gz
	rm -rf ../mercurial-evolve_$(VERSION).orig
	mv hg-evolve-$(VERSION) ../mercurial-evolve_$(VERSION).orig
	cp -r debian/ ../mercurial-evolve_$(VERSION).orig/
	@cd ../mercurial-evolve_$(VERSION).orig && echo 'debian build directory ready at' `pwd`

install-home:
	$(PYTHON) setup.py install --home="$(HOME)" --prefix="" --force

# test targets
TESTFLAGS ?= $(shell echo $$HGTESTFLAGS)

HGTESTS=$(HGROOT)/tests

help:
	@echo 'Commonly used make targets:'
	@echo '  deb-prepare        - prepare the build of a debian package'
	@echo '  tests              - run all tests in the automatic test suite'
	@echo '  all-version-tests - run all tests against many hg versions'
	@echo '  tests-%s           - run all tests in the specified hg version'

all: help

_check_hgroot:
ifeq ($(HGROOT),)
	$(error HGROOT is not set to the root of the hg source tree)
endif

tests: _check_hgroot
	cd tests && $(PYTHON) $(HGTESTS)/run-tests.py $(TESTFLAGS)

# /!\ run outside of the compatibility branch output test will likely fails

test-%: _check_hgroot
	cd tests && $(PYTHON) $(HGTESTS)/run-tests.py $(TESTFLAGS) $@

tests-%: _check_hgroot
	hg -R $(HGROOT) checkout $$(echo $@ | sed s/tests-//) && \
	(cd $(HGROOT) ; $(MAKE) clean ) && \
	cd tests && $(PYTHON) $(HGTESTS)/run-tests.py $(TESTFLAGS)

# build a script to extract declared version
all-version-tests: tests-@

.PHONY: tests all-version-tests