On Fri, Apr 22, 2011 at 2:27 PM, Richard Hipp <d...@sqlite.org> wrote:
> To rebuild the LEAF table from canonical information, run: > > fossil leaves --recompute > > Please try that on both client and server and see if it resolves the > issue. Of course, if it does, we still have to try to figure out why the > LEAF table is getting out-of-sync.... > i've done that on the client and that hid (closed?) one of the leaves, but i'm still left with 2, one unclosable (the one i want t close, in fact). On the server i can't run it because "leaves" requires an open checkout (doesn't support -R) and the server just has the .fsl file: wande...@wanderinghorse.net [~/fossil]# fossil leaves --recompute -R cson.fsl fossil: not within an open checkout This isn't a big deal, just a bit curious. i've never noticed this until a few days ago, so i can't say when it started happening, but it sounds like it's related to the change in recomputation. On this repo i've switched several times in and out of autosync mode across 3 PCs, which has caused me no end of accidental/unnoticed forks. That's why i've ended up with extra leaves in the first place. If i'd leave autosync on i probably wouldn't be seeing this behaviour. Doing a full clone of the repo might also rid my local copy of the extra leaf, but i haven't tried it. i have just found a second repo with the same behaviour: server-side i see only 1 entry under /leaves but under "fossil ui" i'm seeing 3, two of which i cannot close. (i've had autosync-related forks in that tree, too.) On this repo --recompute still computes 3 leaves and two cannot be closed (the two i want to close, strangely enough). Weird. -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
