On 1/9/15, [email protected] <[email protected]> wrote: > 'Lo. > > I've run up against an unpleasant problem. My fossil > repositories are served over CGI, and the CGI program is running on a > hosting provider that treats CPU time as a precious resource. When > cloning a repository that's larger than a few tens of megabytes, > whatever they're using as a cpu time supervisor usually kills the clone > in process before it can be completed.
Please try this: Visit the Admin/Access page and reduce the "Download packet limit". Maybe that will allow the CGI to finish. > > This wouldn't be such an enormous problem if the clone could be resumed > where it left off, but fossil seems to get upset at this: > > $ fossil sync --repository io7m-r1.fossil > Fossil internal error: infinite loop in DELTA table > > This essentially means that many of my public repositories can't be > cloned by anyone! > > An example repository that tends to show the problem: > > http://fossil.io7m.com/repo.cgi/io7m-r1/index > > Cloning means receiving roughly 130mb of data. > > Is there something that can be done to make clones resumable? Given the > transactional nature of repository operations, I'd have expected > resuming to "just work". > Clones are specially optimized so that they run faster. And this is probably interfering with the restart. A push or pull is completely restartable. Perhaps something can be done. Keep pestering people until we have time to work on this. In the meantime, try lowering the Download pack limit as described above. Or: Get a better ISP. ;-) -- D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
