On 3/11/15, David Mason <dma...@ryerson.ca> wrote: > As for what they did, it was a while ago that they set them up. There > was a problem that the students on Linux (typically ubuntu) didn't see > the stuff I had created for them (default .fossil-settings and > assignment directories), which sounds a lot like this problem. I > guess they were never working on trunk. Perhaps if i'd told them to > "fossil update trunk" it would have worked. > > The problem was that the version of fossil that apt-get used was > version 1.27 (I think... maybe 1.29) and I created the fossils with > 1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them). This is > the resource page I point them at: > http://cps506.sarg.ryerson.ca/Resources/fossil.html >
The first visible student check-in is 198f28add5. The manifest for that check-in shows that its parent check-in is a09a968bf05a50058f3ad50132730b719bc39e76. But artifiact a09a968bf05a50058f3ad50132730b719bc39e76 is not a check-in, it is a content file. That means that the 198f28add5 check-in manifest is corrupt. I do not know how that came to be.... Brainstorming... Maybe something like this occurred: (1) Copy the original repository file into xyz.fossil (2) run "fossil open xyz.fossil" (3) Copy a revised version of the repository over top of xyz.fossil (4) run "fossil commit" Copying over a repository with a new version, as is done in step (3), should not be done while there are open check-outs. One should "fossil close" first, then overwrite the repo, then "fossil open" again. That is something we do not check right now - maybe we should. It never occurred to me that somebody might overwrite a repository that was in use with a different repository. Is the scenario above a possibility? -- 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
