[ Xpost on gnu-arch-users and xtla-el-dev ] Hi all,
We're having some (minor) troubles with merging with xtla's development. Our approach is completely distributed. No real main archive, everybody merge from everybody from time to time. The typical session is: 1) Look at missing patches from all the contributors 2) Merge all of them 3) Hack hack hack 4) Commit 5) if (!too_tired) goto 3) 6) sleep. Now, let's take a problematic case. "A" writes something stupid (Err, to be honest, this is inspired from a real situation in which I was "A" ;-). "B" comes and merges the stupid patch from "A" "A" reverts his stupid patch. At this point, "A"'s archive is OK, and "B" has the bug. Now, "C" comes in the game and merges both the wrong patch and the revertion of the patch. (calling star-merge on the latest patch) His archive doesn't have the bug. Now, "C" continues merging from his partners, and merges from "B". Then, he merges the wrong patch again, and at the end of the merge, he has no missing patch and a bug in his local tree. So, the question is: How to avoid that? In our example, if "C" had merged from "B" first, he would have merged the wrong patch, and the wrong patch would have disapeared from the list of missing patches from "A" for "C". Then, "C" would have merged the remaining missing patches, which contain the patch revertion. So, in our typical session above, we should add "1.1) compute the version to merge first". We can't avoid conflicts introduced by concurrent edition of the same portion of file, but we can eliminate those introduced by a wrong merging strategy. The answer is : Merge first the patches that haven't been merged from other partners yet. More formally, we can consider the set of patches as a directed graph. Vertices are the revisions, and an edge A -> B corresponds to the relation "A contains the patch of B". A directed edge induces a timing relation : A was created after B, so, we can be sure there's no cycles here. We have therefore a DAG. At least one of the revisions is therefore a "source". (A vertice with no ingoing edge) So, our problem has (theoretical) a solution :-) I'm now looking for a _practical_ solution: What's the best way to compute the first patch to merge? Has tla a feature to do this? Will it have in the future? Do we have to implement it in the front-end? I'd like to be able to type something like $ tla unmerged-missing version1 version2 version3 version4 That would list the candidates for a clean merge. Thanks for reading till the end, thanks for any kind of advice, ... -- Matthieu
