Here is what I am thinking...

FWIW, that sounds to me like it could/should work. If by F/trunk you mean the logical trunk, named something othef than "trunk" then that wouldn't be a problem until/unless O also uses that branch name.

Related: the main-branch settings tells fossil what the repo's main branch's name is (default = trunk):

https://fossil-scm.org/fossil/help?cmd=main-branch

That might be useful for your F copy.

Wikis use a last-edit-wins approach, so... last one wins. All edits are retained in the history, and there's nothing in the data model which prohibits wikis from branching and merging, but no UI has ever been added to enable those. Embedded docs are generally a better doc format because they're part of the main versioned state, including the ability to branch and merge. With the new fileedit page, those can even be edited online.

All additions to tickets are applied, unless i am very sorely mistaken, in the order of their timestamp, so ticiets aren't likely to be a problem for you.

When setting main-branch, is the intention that when doing a "fossil open" that the checked out copy will be on that branch?

Kinda...

https://fossil-scm.org/fossil/file?udc=1&ln=3054-3058&ci=1243bf39996b8a65&name=src%2Fdb.c

If you specify a version on the command line, it uses that one's branch. If you have a main-branch set but you have not checked in anything to that branch then... i'm not clear what should happen. Presumably, in your case, that branch has never been committed to, so that branch does not actually exist yet, per se, in the SCM history.

Aha... open delegates most of its work to checkout, and checkout, if it cannot find the given version, will fail fatally.

If called like:

fossil open /path/to/repo.fsl

IF the repo has any checkins listed in the timeline, that translates to:

fossil open /path/to/repo.fsl MAIN-BRANCH

Which is then delegated to:

fossil checkout MAIN-BRANCH

If the repo has no checkins listed in the timeline (event table) then checkout will, instead of a version, get passed the --latest flag, which seems to be semantically equivalent to a version of tip.

So...

In your case, if your F/trunk branch has never actually been created (only referenced via main-branch), then i would expect (based on a casual reading of the code) open (via checkout) to fail fatally with a message that F/trunk does not refer to a UUID. If it has been created then i expect open to leave (pun not intended) you in that branch.

that was set on the remote repository?

That's a local config option, not a project-level option. According to src/configure.c, it's not part of the syncable state.

Confirmed. The local main-branch setting is not cloned.

Below is a repro script. This seems to be not an issue when doing a file-clone as opposed to network-clone.

mkdir testrepo
cd testrepo
fossil init testrepo.fossil
fossil open testrepo.fossil
echo "test">f.txt
fossil add f.txt
MAINBRANCH=newtrunk
fossil commit -m "added f.txt" --branch $MAINBRANCH

fossil branch
fossil set main-branch newtrunk
echo "INFO: testrepo main-branch: '" `fossil set main-branch` "'"
fossil close

fossil server testrepo.fossil --port 8888 &
echo "$!" >fossil.pid

mkdir testclone
cd testclone
fossil clone http://localhost:8888 testclone.fossil
fossil open testclone.fossil

fossil branch
echo "INFO: clonerepo main-branch: '" `fossil set main-branch` "'"

curbranch=`fossil branch | grep '^* '`
[ "$curbranch" == "* $MAINBRANCH" ] || echo "ERROR: cloned main-branch setting is incorrect." >&2  
fossil close

cd ..
kill `cat fossil.pid`
rm -rf testclone
cd ..
rm -rf testrepo

In my test this reports the "ERROR:".

I believe this is supposed to be a syncable option. It has project-level relevance (just as "comment-format" is, for example).

The patch below would enable the remote sync of main-branch setting.

Index: src/configure.c
==================================================================
--- src/configure.c
+++ src/configure.c
@@ -148,10 +148,11 @@
   { "parent-project-name",    CONFIGSET_PROJ },
   { "hash-policy",            CONFIGSET_PROJ },
   { "comment-format",         CONFIGSET_PROJ },
   { "mimetypes",              CONFIGSET_PROJ },
   { "forbid-delta-manifests", CONFIGSET_PROJ },
+  { "main-branch",            CONFIGSET_PROJ },
 
 #ifdef FOSSIL_ENABLE_LEGACY_MV_RM
   { "mv-rm-files",            CONFIGSET_PROJ },
 #endif

+ { "main-branch", CONFIGSET_PROJ },

It's not a bug - that's not synced by design.

It's not a bug - that's not synced by design.

It's not clear from your statement, what's the reasoning for excluding "main-branch" setting. The way I read it, you suggest that there is a specific consideration for excluding this setting.

It's not clear from your statement, what's the reasoning for excluding "main-branch" setting. The way I read it, you suggest that there is a specific consideration for excluding this setting.

Pardon my previous brevity - working from a tablet makes long/detailed responses tedious.

i don't know the reasoning of whoever initially added that setting, but after seeing that it was defined as un-syncable it became clear to me that i would not want someone else defining what should be the "main" branch on my local copy of a repo. e.g. if i'm working primarily on a long-lived branch other than the main trunk of some project i've forked, i don't want someone else's idea of "main branch" interfering with that.

i can understand why a project would want to define this at the project level, but sympathize more with people who want to set it independently of the project they're synching from. We can't give "main-branch" two different meanings, so my preference would be to leave it how it is - not synced.

i don't know the reasoning of whoever initially added that setting

Thanks for describing your understanding of this.

Here's how this setting is defined:

The "main-branch" setting:
    The value is the primary branch for the project.

That is the "main-branch" is a project-level setting. It's not meant to be flipped for convenience. There are other equally project-level settings yet which are sync'able.

The "main-branch" setting: The value is the primary branch for the project.

That is the "main-branch" is a project-level setting.

That's certainly the implication of that description, but the description might not have initially been intended to mean "project" as an "project-wide," but "project" as in "this copy of the project." i can't say for sure - it was not my addition.

There are other equally project-level settings yet which are sync'able.

One example is the new fileedit-glob. It's conceptually a project-level setting but if it's made syncable or versionable then someone else may change the default behaviour of someone else's repo, perhaps inadvertently, and, as Egon Spengler put it, "that would be bad."

i think what it comes comes down to is whether or not the changing of the preference could change how someone else's copy of a repo behaves, possibly without them knowing/realizing/desiring it. Making main-branch sync definitely falls into that category of change.

It's not clear from your statement, what's the reasoning for excluding "main-branch" setting.

To me, it makes sense that the main-branch setting be local-only. At least by how I understand branch naming in Fossil.

I may be wrong, but as I understand Fossil branch naming, a branch begins with a commit tagged with a branch=Name propagating tag. So, any sequence of commits that is not otherwise named by a branch tag is named by the value of main-branch. (When a commit is made, it inherits its parent's branch, unless it is tagged with a branch tag.)

Usually, this "nameless" branch starts with the "Initial empty commit", which, when created, has no branch tag. By default, Fossil displays the name of this branch as "trunk". If you set main-branch, then that is used instead of trunk.

If you tag the initial empty commit with a propagating branch tag, then (1) all those "trunk" commits will become members of this new, named branch, and (2) the main-branch setting will, effectively, be ignored.

(Unless your repo has more than 1 trunk. Then the branch tag will, of course, only affect one of those trunks.)

Again, I may be misunderstanding how Fossil branching works. But, if I'm correct, then the main-branch setting is only cosmetic.

Either way, if you want a project-wide main branch name, try:

    fossil amend --branch NAME HASH

where HASH is the commit ID of the first commit on "trunk".

It seems that the whole point of the setting is lost otherwise?

One use of the setting is lost, yes, but another (see my previous response) is not. There's no objective way to decide which of those two uses is more valuable, but if we suddenly make it syncable, after it previously was not, we irrevocably break the other use (with no workaround). If we leave it unsyncable then at least the other use continues to behave how it historically has.

Isn't it also slightly confusing if cloning from a file, sets it accordingly. While from a URL it does not?

That feels like a bug to me. Cloning "should" (IMHO) behave identically regardless of the way the source is accessed.

The semantics would be that if main-branch is empty, use default-main-branch.

This would keep everyone happy I think?

i'm not personally averse to it, but i wonder if it's really needed. So far it hasn't been, and your use case can be implemented without it: simply set main-branch to F/trunk on the clones which need it?

Quoted from my response to our anonymous poster:

i think what it comes comes down to is whether or not the changing of the preference could change how someone else's copy of a repo behaves, possibly without them knowing/realizing/desiring it. Making main-branch sync definitely falls into that category of change.

Changing its behaviour, or changing the value of main-branch after it is made synchable, could indeed lead to...

causing all kinds of messy behavior.

Potentially repeatedly, as an admin changes their mind about the main branch name.

i'm not fundamentally against adding a specifically synchable setting which acts as the project-wide default for main-branch (with the latter taking precedence), but (again) i'm not convinced that it's needed, nor am i convinced that it wouldn't have fallout of its own when a project admin changes it willy-nilly and thereby changes default behaviours in downstream clones which aren't expecting it.

That said, if someone else wants to implement it, and update the... 7(?)... places which check main-branch, i won't fight it.