On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote: > >>But the real problem is why does it think the branches are in a loop? I haven't figured it out yet either; mine didn't detect the loop though, it just ended up spinning in the tsort code, unable to compute a valid order to execute branches in. Something funky must be up with the mozilla branches. What this code does is find an order that will 'work' when computing branch contents. The requirement is that the 'parent' branch be computed before any 'child' branches. It does this with a nice quadratic algorithm, building a list of 'ready' branches who have no 'unready' dependencies in any of the incoming file objects. If there are conflicts where one incoming file shows branch 'B' as the parent of branch 'A' while another shows branch 'A' as the parent of branch 'B', the sorting cannot succeed. Ideally, I'd figure out a way to eliminate the parent/child relationship and just treat the branches as peers with a common ancestor. I haven't figure out how to manage that yet; attempting to find the precise divergence point where the child forks from the parent remains complicated, it seems like trying to do that without a strong parent/child relationship would be even more error prone. Better error messsages here would clearly help discover which branches were in conflict, and show the files causing problems. -- keith.packard@intel.com - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2.1.8 : 2006-06-17 15:32:17 EST