On 6/17/06, Keith Packard <keithp@xxxxxxxxxx> wrote:
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.
Have you checked parsecvs on the 38 test repositories in the cvs2svn source?
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEk5OGQp8BWwlsTdMRAuyZAKC3URBHR/SWgG7azMqKe3efGNxNZwCdFAVA GEIKF8z/MtdbBnKRMDneSH8= =ShEA -----END PGP SIGNATURE-----
-- Jon Smirl jonsmirl@xxxxxxxxx - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html