> On Feb 2, 2015, at 3:28 PM, Joerg Sonnenberger <jo...@britannica.bec.de> > wrote: > > On Mon, Feb 02, 2015 at 03:23:46PM -0700, Warren Young wrote: >> >> Are you seriously asking for Fossil to allow a local clone to be in an >> inconsistent state after an error? > > Why does it have to be an inconsistent state? At the very least, it > could ask for isatty(stdout) whether it should just retry.
SQLite already has retry behavior in its locking. I presume Fossil hasn’t disabled that. After sending that prior message, I did think of a way to allow retries without inconsistency, but it would surely slow Fossil down: there could be a mode that turns cloning into a replay of the master repo’s timeline. That is, every change made to the master gets applied to the slave, in the order it was made. This means local files get updated multiple times, even if later changes wipe out prior ones. The advantage is that after each changeset is applied, the tree is again in a consistent state. That might not help the NetBSD repo, though, depending on how it was constructed. If it’s a history-preserving conversion from CVS or similar, this would possibly work. If on the other hand there was a point where a huge existing tree was imported into an SCM (Fossil or a predecessor) as-is, you have a good chance that the timeout will happen during processing of that initial huge commit. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
