You can move the check-out around. You just can't move the repository. The ".fslckout" file in the check-out contains the full pathname of the repository (among other things), which is how Fossil locates the repository.

We could store a relative pathname in .fslckout, but then if the repository is separate from the check-out (which is the usual case with Fossil) the link would be broken when the check-out moved.

Maybe you want to store the relative pathname in .fslckout only when the repository is in the check-out. Then it would work whenever you move the check-out. But it seems like a brittle and complicated solution to an unusual problem. I'm not yet sure we are seeing all the corner cases.

You can use the fossil test-move-repository command to adjust the pathname to the repository in the .fskckout file.

Here's an idea:

Suppose we continue to store the absolute pathname of the repository in .fslckout, as we always have. But, further suppose that if when we go to look up the repository, if we can't find it, we also look for a file with the same name in the root directory of the check-out.

Presumably xerusf's complaint comes up because he has had prior exposure to Git, where the repository is the .git directory in the checkout, so he is used to being able to move the entire checkout around it it will just work. Probably others are coming from Git had have the same old habits. With the change outlined in the previous paragraph, things would continue to work as former Git users expect.

What am I missing?

Can putting the repo file in the working directory result in commiting the fossil repo to the fossil repo? I seem to remember this being a potential issue and why it's not suggested.

One possible workaround is to support the repo in the parent directory. This would work for USB where the repo and the working directory can share the root directory of the disk.

Fossil is careful not to commit it's own repository file.

I seem to remember this being a potential issue and why it's not suggested.

It's not an issue per se but can lead to user errors which can corrupt a repo. Many years ago i did some C-style refactoring using a one-line perl script to replace some text throughout my project. Predictably, doing so corrupted my repo db through no fault of fossil's. Since then i adamantly keep repositories outside of my checkout dirs.

Why can't fossil just use relative paths?

While developing and testing my proposal at (3.1) above, I discovered that the repository filename is stored as a relative path, or at least it usually is. And so my changes are not actually necessary.

If you open the check-out using:

fossil open ./myproject.fossil

Then the pathname stored is literally "./myproject.fossil", in which case you are free to move the checkout around all you want. Only if you do this:

fossil open /full/path/to/myproject.fossil

Does the repository filename become absolute and locked into place. How did you open the repository in question? From the check-out, if you run:

fossil sql "SELECT value FROM vvar WHERE name='repository';"

What does it say?

Answering my own question: It appears that if you do

fossil open https://domain/repo

That it stores the absolute pathname. Perhaps if we just fix "fossil open" so that it sets the "repository" entry in VVAR to a relative pathname, that would suffice to resolve the problem, and the magic repository search algorithm proposed in (3.1) would not be necessary?

The proposal at (9) has now been checked in.