Can I hide branches from Reader logged in users? Or have private internal data?
(1) By patmaddox on 2023-05-12 01:18:40 [link] [source]
I want to have different access to three branches:
- trunk: public
- beta: logged in Reader users
- alpha: logged in Developer users
Can I do that with Fossil? I suspect no...
I am able to restrict public to trunk by using public pages. So now nobody users can see trunk, but no other branches.
I have experimented with private branches, and from what I can tell, private has to do with whether it syncs automatically. When I fossil sync --private to push my private branch to a remote repo, then any logged in user can see it.
In other words, if I can see one branch on a Fossil server, I can see all of the branches on the server. Is that correct, or is there something I'm overlooking?
Child Projects - close, but not quite
Assuming that I can't hide branches from logged in users, I think the necessary approach would be to use child projects. Beta branch is in the main repo that users can log into, and alpha branch is a child project that only I can access. I have worked that out.
Private internal data?
The rub with child projects is that I want this data to live in the main repo - I just don't want it to be accessible to logged in users. There are two reasons I want it in the repo: 1) there's a single repo for me to clone to get all the data 2) I want to write CGI extensions that access and modify the data. My plan was to commit that data to a private branch - but I believe that Fossil doesn't support hiding specific branches, even private ones.
So... if that's the case, one thing I could do is have my web server route /ext/ requests to a child project "admin" fossil that modifies the data. Users aren't logged into that one, but a subset of web requests go there. I like that because again I have a single file to back up - this time it's the child repo.
I am wondering: does Fossil have any notion of private data that I can access from a CGI extension? Because that would be a way I could have a single main repo, avoid the child project, and prevent Reader users from seeing this data.
(2) By Stephan Beal (stephan) on 2023-05-12 01:40:30 in reply to 1 [link] [source]
Can I do that with Fossil? I suspect no...
Short answer: no
Longer answer: nope
I am wondering: does Fossil have any notion of private data that I can access from a CGI extension?
Fossil's features are developed almost exclusively to scratch the "personal itches" of its own developers and none of us have been itched by such a thing enough to feel compelled to scratch it.
(3.1) By patmaddox on 2023-05-12 23:08:39 edited from 3.0 in reply to 2 [link] [source]
Longer answer: nope
:)
Fossil's features are developed almost exclusively to scratch the "personal itches" of its own developers and none of us have been itched by such a thing enough to feel compelled to scratch it.
I've been reading a bunch and come across this idea for a knowledge management system, which led me to RFE: A Personal Database System. Interesting stuff, but it would seem not itchy enough yet.
In reviewing my own post, I realize I'm mixing up two different things:
Truly private branches
Two ways to do this: child projects, or a shared and private remote repo. fossil sync to the shared repo, and fossil sync --private to the private repo.
Private data
The RFE I linked above is headed in that direction, though that thread has not seen activity for a couple years.
It seems that, today, the straightforward solution is for my CGI extensions to access their own database independent of the fossil db.
(4) By Andy Bradford (andybradford) on 2023-05-12 02:56:28 in reply to 1 [link] [source]
> I want to have different access to three branches: I thought for certain there was a document that mentioned the fact that in a Fossil repository, all branches are accessible to all users (except for private branches which are only available in the repository where the branch exists). The closest I could find is: https://www.fossil-scm.org/home/doc/trunk/www/gitusers.md#syncall https://www.fossil-scm.org/home/doc/trunk/www/private.wiki Instead of trying to bend Fossil into 3 different paradigms, what about rethinking the approach? Do you really want beta and alpha users to have access to the main Fossil repository and hence it's timeline and all code? If they don't really need this, why not just export the code identitifed by the "beta" branch as a static .zip (or .tar.gz) and publish that to them when the "beta" is tagged? Andy
(5) By patmaddox on 2023-05-12 03:13:18 in reply to 4 [source]
Instead of trying to bend Fossil into 3 different paradigms
What are the three different paradigms? Fossil already has RBAC for high-level functionality and resources, and a mechanism for making certain file globs visible. It's not a stretch to be a bit more granular with RBAC and say that certain users have access to specific branches.
Do you really want beta and alpha users to have access to the main Fossil repository and hence it's timeline and all code?
I see what you're saying, and it brings up a point I hadn't mentioned: I wasn't planning for any of these users to have clone access.
So yes, I'd want a single repo where I can do anything; logged in users can view the timeline and code for beta branch; and nobody users can view the timeline and code for trunk. But I'm imposing the constraint of not permitting clones, which is fine for the specific example I'm thinking of, but is probably too limiting for a general case.
Why not just export the code identified by the "beta" branch as a static .zip (or .tar.gz) and publish that to them when the "beta" is tagged?
Because I want people to be able to navigate the code on a website, investigate history, link to it from forum and tickets, etc.
(6) By Warren Young (wyoung) on 2023-05-12 13:45:22 in reply to 5 [link] [source]
I wasn't planning for any of these users to have clone access.
Good, because your wished-for scheme falls apart completely if you do. Fossil does not today — and likely never will — allow partial syncs based solely on logged-in user ID and branch name, glob, etc. The current extent of our wildest dreams are to support shallow and narrow clones, and each of those are upgradable to full clones the moment it's needed.
For it to be otherwise, Fossil would have to parse and filter each committed blob during sync. That would not only add a lot of overhead to the sync process, it would potentially allow "leaf" commits to have an inconsistent or even broken view of the repo they cloned from due to holes shot in the DAG, merges that go nowhere, merges that come out of nowhere, etc.
If you were then to stand that broken clone up as a new server, you'd risk all kinds of havoc when someone then attempted to commit to it.