On Fri, Apr 22, 2011 at 8:48 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> 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. This seem likely to be a bug, compounded by the following truths: (1) The definition of "leaf" is not a straightforward as it sounds - determining what is and what is not a leaf is a subtle problem. (2) Following from (1), the definition of "leaf" has changes a few times during the history of Fossil, and probably a few cases were missed at each change. (3) The primary author and maintainer of Fossil (yours truely) rarely pays any attention to leaves and is thus not likely not notice problems in their computation. On the other hand, I cannot think of any serious problems that can arise from a miscomputed leaf. This issue seems to be more of an annoyance and irritant than a work-stopper. Nevertheless, I'll poke around and see if I can spot something wrong. It would help if you could send me one or more of your repos that are showing leaf problems, via private email to d...@sqlite.org. Thanks. > > -- > ----- 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 > > -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
