Richard Hipp <drh@...> writes: > > > On Thu, Mar 14, 2013 at 3:53 PM, Baptiste Daroussin <baptiste.daroussin- re5jqeeqqe8avxtiumw...@public.gmane.org> wrote: > > > > > The timewarp is likely a git->fossil conversion bug. (Not necessarily a > > fossil bug, as there is no shortage of bugs in git-fast-export). It might > > be worth while try to trace down this import bug. If you can give us any > > clues, that would be appreciated. > > > > > Would be hard it was very long time ago and I don't have anymore the > original git repo. > I dropped it as soon as I jumped on fossil :) > > > Bummer. We'd probably need the original git repo in order to track down the problem.Meanwhile, to work around your slow annotations, you can limit the number of historical queries that are examined by using the "--limit N" command- line option or the "limit=N" query parameter, as appropriate. For example, https://fossil.etoilebsd.net/poudriere/annotate? checkin=bbbfd3a9d07e6690&filename=src/share/poudriere/common.sh&limit=30is quite fast. But you might need to increase the 30 to dig back far enough in the past to see the changes you want.Hmm.... If you add the "log" query parameter, the annotator also shows you which check-ins it examined in order to compute the annotation. If I add &log&limit=800 (see https://fossil.etoilebsd.net/poudriere/annotate? checkin=bbbfd3a9d07e6690&filename=src/share/poudriere/common.sh&limit=800&log) and if you scroll down, you can see that the annotator really does enter an endless loop starting at about 716. I'll see if I can fix that.... >
Not sure if this helps. I actually have been exporting this fossil repo back to git as well. This has raised some challenges due to the timewarps. The git fast- import complains about out-of-order commits. # fossil test-timewarp-list d519de7ebd045c8eb5b9b354ac072e04e8d30dbd 264adb8789507b9b76baaddc2a7cc0da10a18b0e I manually hacked at a fossil checkout of this repo to allow it to export to git. I analysed the repo last year and ran these commands to fix the ordering of some commits, and remove some of the commits causing the loop as well. This operation has *not* been done on fossil.etoilebsd.net/poudriere though. $ echo "SELECT * FROM blob WHERE rid IN (962,960,964,958);"|sqlite3 poudriere.fossil 958|1|1513|103d081e348366c41136e4a4d46c7de5dae2dc33| 960|1|1506|98ac7ceb60a308de673d0173f774dfd776306709| 962|1|1498|d519de7ebd045c8eb5b9b354ac072e04e8d30dbd| 964|1|1505|c9c2dc0326b02408b11c0180b27fdc7225c7b2be| $ echo "SELECT * FROM plink WHERE cid IN (962,960,964) OR pid IN (962,960,964,958);"|sqlite3 poudriere.fossil 958|960|1|2456049.87217528 960|962|1|2456049.86332123 962|964|1|2456049.91145751 960|2615|1|2456216.24479052 964|966|1|2456050.29082854 pid|cid 958 -> 960 -> 962 -> 964 958|960|1|2456049.87217528 960|962|1|2456049.86332123 962|964|1|2456049.91145751 958 -> 962 -> 960 -> 964 958|962|1|2456049.87217528 962|960|1|2456049.86332123 960|964|1|2456049.91145751 UPDATE plink SET pid = 958, cid = 962 WHERE pid = 958 AND cid = 960; UPDATE plink SET pid = 962, cid = 960 WHERE pid = 960 AND cid = 962; UPDATE plink SET pid = 960, cid = 964 WHERE pid = 962 AND cid = 964; DELETE FROM plink WHERE pid = 148 AND cid = 212; DELETE FROM plink WHERE cid = 155; DELETE FROM plink WHERE cid = 6; Regards, Bryan Drewery _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
