This is either a bug report or a clue for anybody unfortunate enough to see this problem some day.

I was trying to create a checkout in what looked like a clean directory, thusly with the result shown: larrybr@bit-bluster:~/SQLiteOrg/SqliteLib/TrunkTip$ fossil open ../sqlite.fossil trunk Unresolved RID values: 1908 2240 2982 ... 93472 93475 93477 93479 93487 , where ... stands for about 1900 more values, about evenly distributed in the range shown.

This was bizarre and repeatable, inducing me to update fossil on that machine and where the repo was cloned from, and re-clone the repo. I finally figured out that my "clean" directory, which looked clean after a "rm -r *", still had a small set of hidden files (with '.' prefixes), which apparently causes the above bizarre behavior. At least, once those files were also oblitered, the "open" proceeded normally.

I am inclined to label this a bug because, even if I flubbed in my naive rm use, the response is unusually unhelpful as compared to Fossil's norm. If I get general agreement on this point, I will see about fixing it. I would think that Fossil's warning about a checkout into a dirty directory might apply when its own litterstuff remains.

And for future stumblees, "rm -r .* *" is the better cleaner.

(Amendment:) This post gives some explanation of what is happening when Fossil's hidden bookkeeping files are left in a directory subject to "fossil open".

(Amendment^2:) "fossil close --force" is probably an even better cleaner. (Next time!)

This was bizarre and repeatable

The only(?) explanation for unresolved RIDs is when a given repo clone is replaced via another copy. Ah, i see you've discovered a post which goes into detail about that, so will consider this resolved. To elaborate a bit, though...

I am inclined to label this a bug because, even if I flubbed in my naive rm use

fossil rm doesn't delete anything in the repo - it just tells fossil not to add the rm'd content in the next manifest. RIDs don't refer to filesystem-local content, so /bin/rm'ing local files won't trigger any sort of RID mismatch.

BTW, the term RID, in fossil jargon, specifically refers to the blob.rid db field. Those values, unlike the blob.uuid field, are specific to any given repository clone and are never exposed to the outside world (e.g. via URL parameters and whatnot). They're used for db-internal relational mapping, in place of the hashes, for efficiency's sake.

And for future stumblees, rm -r .* * is the better cleaner.

FWIW, i generally do:

$ rm -fr .[a-zA-Z]* *

The confusing "Unresolved RID values" response occurred after I decided to zap a checkout and start over, using /usr/bin/rm . (I would hesitate to use "fossil rm" in such a drastic way, for fear of a later accidental up-sync or push.)

The sequence was:

Would you agree that "fossil open" into a non-empty directory should get the same, directory ... is not empty use the -f or --force option to override response induced by non-Fossil files being present?

Would you agree that "fossil open" into a non-empty directory should get the same... response induced by non-Fossil files being present?

i didn't know that fossil is choosy in that regard, and that it simply looked if the dir contained anything at all. Currently i'm on a tablet under 2 sleeping dogs, so won't confirm that ;).

1. See that workstation repo timeline does not reflect fix #3.

Something like that's been reported a handful of times over the years. Mostly it's caused by lack of permissions on the push and people overlook the "not permitted to write" message. In other cases, adding the --verily option to the sync command has resolved it.

(Pardon brevity... sleeping dogs.)

Would you agree that "fossil open" into a non-empty directory should get the same,

directory ... is not empty use the -f or --force option to override

response induced by non-Fossil files being present?

Fossil should detect and warn about the presence of "other" files in the checkout dir. The "other" files should exclude the repository db-file being opened. This is to cover the case when repository is init'ed and opened from the same dir.

I understand Fossil does this self-check already, just it probably is too liberal in also allowing the checkout-db (.fslckout) to be present at open even though it's remnant from previous incarnation of the repo.

Once the repo is open, Fossil already knows how to exclude its own auxilliary files from the rest of the managed/unmanaged groups.

... just it probably is too liberal in also allowing the checkout-db (.fslckout) to be present at open ...

For me, fossil open seems to check for the checkout-db:

if I do (from an open checkout):

rm -r *.  # this doesn't delete the .fslckout file
fossil open path/to/repo.fossil

I get the following warning:

there is already an open tree at ...

In an simple test of reusing a "dirty" checkout dir, I get a different Fossil error: "repository does not exist or is in an unreadable directory:"

mkdir t
cd t
fossil init t.fossil
fossil open t.fossil
echo "file1" > f1
fossil add f1
fossil commit -m "f1"
echo "edit" >> f1
fossil diff

rm *
ls -a

.  ..  .fslckout


fossil init new.fossil
fossil open new.fossil

repository does not exist or is in an unreadable directory: /path-to/t/t.fossil

For step 8, I assume you didn't close and reopen the repo, which would cause this symptom. This is the "repo clone is replaced via another copy" Stephan referenced. The per-checkout .fslckout file refers to RIDs not in existence in the new clone, giving the error.

If you close and reopen the checkout when the repo DB is replaced, the RID error won't occur.

Now, if you want to take up how you got to step 4, which led to the rest of your trouble, that might be a more productive discussion.

Your assumption re step 8 is correct. (I tried to include relevant repro.)

At this point, the discussion has been productive enough to probably preclude any future encounter with the puzzling subject behavior, for me.

I grant that I flubbed by not using "fossil close". However, I still maintain that fossil would be improved by issuing the "directory ... is not empty" error on any (not --force'd) open attempt involving a non-empty directory, whether the content is known to Fossil or not. The non-emptiness probably means a flub is in progress and warrants a rethink or some research. The presence of Fossil-known files might even trigger a more specific tip: "use the close subcommand".

It was the notion that a blizzard of "Unresolved RID values" is an unduly opaque response to a semi-innocent¹ error that led to my post. And if that notion evolves into a consensus among Fossil devs, I will consider the discussion so far to have been as productive as I envisioned.

On my step 4, (a pushed revision not showing up in the pushee repo), I have to say it was quite a puzzle. I was looking for anything untoward as the "fossil push" ran, and there was no such thing. (I've seen auth failures often enough at this point to have been ready for that; it was a newly setup machine and grandchild repo.) All the usual little clues about wire traffic appeared, and it looked like a completely normal, successful push; it just did not take. I was pretty sure something was broken, hence my replacement of binaries and heavy-handed use of rm. Now, the tangible evidence is gone, so I cannot repro the step 4 problem or say much on it, productively.

1. My innocence is limited in that I have not yet mastered all the ins and outs of using Fossil for unusual cases, and yet try to use it anyway.

it was quite a puzzle...the tangible evidence is gone, so I cannot repro the step 4 problem

Did you perhaps forget to do "fossil up" on the pushee? All pushing changes from one repo to another does is update the target repo: it doesn't move any checkouts made from that repo to the just-pushed state.

My "did not take" conclusion was based on the timeline visible after "fossil ui" on the target ("pushee") repo.

I may have fibbed re "cannot repro ...". I did a push today from that grandchild repo to the child repo and got the "not authorized to write" error. While I can hardly believe I missed that yesterday, I am sure that the same issue must have existed then. (Maybe I confused packet counts with artifact counts.) So I guess that dispenses with all but the "Unresolved RID ..." opacity as an error output.

My "did not take" conclusion was based on the timeline visible after "fossil ui" on the target ("pushee") repo.

When you see such things, be sure to try a hard reload. Firefox very often likes to show me old timeline content from localhost when running (fossil ui). Tapping shift-reload (or is it ctrl-reload?) is necessary to force it to reload the content.

Firefox very often likes to show me old timeline content from localhost when running (fossil ui).

Is it something recent? I noticed it only this year. Don't remember needing any forced re-cache before that.

I thought Fossil had some ways to inform browsers that the served pages are updated.

Is it something recent? I noticed it only this year. Don't remember needing any forced re-cache before that.

That matches my experience. Maybe the past 6-8 months or so? Not sure, but it didn't always do that.

i don't recall ever having any problems with this when accessing a remote site, only over localhost via fossil ui, but will keep an eye out for that.

I thought Fossil had some ways to inform browsers that the served pages are updated

For what is effectively static content, e.g. each separate set of skin CSS and fossil's own compiled-in files (e.g. non-skin JS), it has aggressive pro-caching measures in place. For page-level routes it does not (insofar as i recall off hand, anyway). For certain expensive-to-generate content, e.g. /zip and /tar, it optionally maintains a separate cache of generated zip/tar files and can apply client-side caching-related measures to those.

For page-level routes it does not (insofar as i recall off hand, anyway). For certain expensive-to-generate content, e.g. /zip and /tar, it optionally maintains a separate cache of generated zip/tar files and can apply client-side caching-related measures to those.

ETag caching has recently been enabled for the /timeline page.

However, because the Fossil-internal HTTP server uses the HTTP/1.0 protocol, which doesn't yet support conditional requests, the caching usually won't work for local servers -- at least the Chromium web browser ignores ETag headers from HTTP/1.0 replies, and does not perform revalidation with If-None-Match requests.

For Fossil CGI requests, where the web server usually upgrades the reply to HTTP/1.1 or HTTP/2.0, the timeline ETag caching should work, and it should account for new check-ins due to the ETAG_DATA flag. However, I was also under the impression that this sometimes didn't work as expected for the /timeline page, so removed the feature from my private Fossil build.

What method did you use to verify that the revision was not in the pushee repo?

fossil ui

Also, what version of Fossil are you using?

It was 14.? from the Ubuntu 21.4 repo until I replaced it with 15.1 .

Please also see this slight walkback.