Re: parsecvs and unnamed branches

On Sat, 2006-06-17 at 00:15 -0400, Jon Smirl wrote:

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.