From: Jon Smirl Date: Sat, 17 Jun 2006 05:51:59 GMT Subject: Re: parsecvs and unnamed branches Message-ID: <9e4733910606162251i65021336m4388d4da715befc9@mail.gmail.com> In-Reply-To: <1150522246.6983.52.camel@neko.keithp.com> On 6/17/06, Keith Packard 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@intel.com > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQBEk5OGQp8BWwlsTdMRAuyZAKC3URBHR/SWgG7azMqKe3efGNxNZwCdFAVA > GEIKF8z/MtdbBnKRMDneSH8= > =ShEA > -----END PGP SIGNATURE----- > > > -- Jon Smirl jonsmirl@gmail.com