Wiki for private branch gets synchronized
(1) By anonymous on 2022-06-04 13:49:59 [source]
I've noticed that wiki pages associated1 with private branches get synchronized. They are then visible in the public repo under
- /timeline?y=w
- /timeline?y=all
- /timeline?r=priv-branchname
- /wiki?name=branch/priv-branchname&p
- /whistory?name=branch/priv-branchname
The private branch itself and its commits are not synchronized, but the wiki page (incl. all its history) is.
Is this the intended behavior?
Technically, the wiki itself is not part of the branch. But then again, the branch is marked private, so intuitively one would expect it's not synchronized.
- ^ For example wikis like "branch/PRIVATE-BRANCHNAME"
(2) By Stephan Beal (stephan) on 2022-06-04 13:58:49 in reply to 1 [link] [source]
Is this the intended behavior?
That's as designed (though very probably not intuitive). Wikis pages are not full-fledged members of the versioning system. They are versioned in their own "namespace," separate from all file-level content, and do not take part in branching, merging, etc. A wiki named branch/... is treated, in some contexts, as being associated with a branch, but it's not part of the branch as far as the underlying artifact mechanism is concerned.
That said: private branches are not something most of us use, so this is likely a use case which has simply gone unnoticed until you pointed it out. An easy solution which treats such wiki pages as private content does not readily come to mind.
(3) By anonymous on 2022-06-04 14:23:01 in reply to 2 [link] [source]
Thanks for the clarification.
The only solution I found was to shun each artifact from the wiki page's history1 in the public repo and then fossil rebuild it.
I probably have to do it in the local repo too, because future edits to that wiki will get synchronized.
- ^ /whistory?name=branch/priv-branchname
(4) By Stephan Beal (stephan) on 2022-06-04 14:36:54 in reply to 3 [link] [source]
I probably have to do it in the local repo too, because future edits to that wiki will get synchronized.
The hashes of shunned artifacts are remembered until you unshun them, so those will not sync again. However, new versions of those wiki pages will sync (they'll just be missing the historical versions in the repos where those were shunned).
You can use:
fossil config pull shun
to pull the list of shunned hashes from your server to your client. Use fossil config push shun to go in the other direction.
(5) By anonymous on 2022-06-04 14:40:11 in reply to 4 [link] [source]
Oh cool, that's useful. Thanks.
(6) By Stephan Beal (stephan) on 2022-06-04 14:41:25 in reply to 2 [link] [source]
A wiki named branch/... is treated, in some contexts, as being associated with a branch, but it's not part of the branch as far as the underlying artifact mechanism is concerned.
A related side note: a branch name can be changed at any time, and if that happens then wiki pages which use the old branch name will no longer be associated (in any context) with that branch. That further complicates the concept of making branch/... wiki pages private if the branch is private. Similarly, if a different (semantically speaking) branch is created with the same name as an older branch for which a wiki page was created, that new branch will also have that wiki page associated with it. That is just to reiterate that wiki pages are not actually part of a branch - they simply follow a naming convention which permits them to be associated (in some contexts) with a given branch name.