Re: parsecvs and unnamed branches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]