Re: parsecvs and unnamed branches

[Keith Packard <keithp@keithp.com>]

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]