Fossil Forum

multi repo / project in single db file, same user-management
Login

multi repo / project in single db file, same user-management

multi repo / project in single db file, same user-management

(1) By anonymous on 2019-08-20 06:59:45 [source]

Hello,
  Am a fossil newbie, so may have messed up some of concepts. 

  We are few people working on few independent softwares.

  Ideally we'd want :
    --> A Single DB file to have multiple independent repositories.
    --> Username / password / groups shared across all repos.

 Is it possible with fossil ?

TIA,

(2) By Warren Young (wyoung) on 2019-08-20 07:17:09 in reply to 1 [link] [source]

I can't tell if you're asking for one feature or two. Is the wish for a single unified repo DB file just your idea of a way of unifying login details, or do you want it for some independent purpose?

The unified login scheme does exist in Fossil: Admin → Login-Group.

(3) By Stephan Beal (stephan) on 2019-08-20 08:10:40 in reply to 1 [link] [source]

A Single DB file to have multiple independent repositories

No. All user accounts/access permission in one repository db have access to everything in that db. There is no way to tell fossil that Bob can only check in to abc/ while Alice can check in to abc/ and def/.

A repo db in fossil is an atomic unit, in the sense that it cannot be broken down into multiple independent "zones" or "subprojects". Any such partitioning of a project tree is a project-level policy, not something fossil can enforce.

If you need projects with different permissions/users, use multiple repos and, like Warren said, login groups.

(4) By anonymous on 2019-08-20 14:32:38 in reply to 3 [link] [source]

Maybe we should add better docs for login groups - more than just the manpage.

(5) By Stephan Beal (stephan) on 2019-08-20 14:36:51 in reply to 4 [link] [source]

i'm not certain that anyone other than Richard is familiar enough with them to do that :/. (i've never used them, though the recent addition of a CLI interface makes them far more appealing to me than they used to be.)

(6) By Richard Hipp (drh) on 2019-08-20 15:20:35 in reply to 5 [link] [source]

Perhaps the pronoun in my previous post should be interpreted as the royal "we". :-)

(7) By Stephan Beal (stephan) on 2019-08-20 17:50:54 in reply to 6 [link] [source]

LOL! It was posted as anonymous, so i didn't realize it was you (The Royal You) ;).

(8) By Andy Bradford (andybradford) on 2019-08-21 14:30:22 in reply to 1 [link] [source]

>  Ideally we'd want :
>    --> A Single DB file to have multiple independent repositories.
>    --> Username / password / groups shared across all repos.
>
> Is it possible with fossil ?

Yes,  it is  possible, though  you probably  want to  reconsider because
it  might be  more  headache  than it's  worth  and  it's generally  not
recommended---I may even be flogged for giving you this information.

Fossil  is  capable  of  handling  multiple  DAGs  in  a  single  Fossil
repository, but you have to take care to keep the names of your branches
unique  in  the different  timelines  or  you'll  end up  with  spurious
warnings about  forks. For  some interesting reading  on the  topic, see
[1], [2], and [3].

In that last thread I actually gave a recipe for how to accomplish it by
taking multiple independent Fossil  repositories and combining them into
one single repository, here:

https://marc.info/?l=fossil-users&m=144565865345756&w=2

While it's easy to get into this kind of setup, I'm not sure how easy it
would be to unravel it later if you decide you don't like it. :-)

As others on this thread have said, all independent timelines will share
the same username/password  but that sounds like  something you actually
want.

That being said, why do you think  it would be easier to manage a single
DB with multiple independent timelines than it would be to simply manage
independent DBs?

Just  out   of  curiosity,  is   there  anyone  still   managing  Fossil
repositories like this?

Thanks,

Andy

[1] https://marc.info/?t=144565821400003&r=1&w=2
[2] https://marc.info/?t=144565829000005&r=1&w=2
[3] https://marc.info/?t=144565865100002&r=1&w=2

(9) By anonymous on 2019-08-21 19:52:12 in reply to 8 [link] [source]

Just out of curiosity, is there anyone still managing Fossil repositories like this?

Thank you Andy for sharing. I am using this approach to track differences between Application on DEV/ACC and PRO servers since February 2015.

On each server, there are several repos (tracking important sub-directories), all repos from all servers are synced into one "merged" repository. It provides invaluable views into differences between environments.

I wish, I could "open" repo in a root directory of server (I have read rights only, no way to have write there) without need to place .fossil there.

On the down side I see no friendly/local way to decompose/simplify merged repo into some meaningful slice (except heavy artifact shunning or privacy evading GitHub involving process by Offray)

(10) By Martijn Coppoolse (vor0nwe) on 2019-08-22 09:26:49 in reply to 8 [link] [source]

Fossil is capable of handling multiple DAGs in a single Fossil repository, but you have to take care to keep the names of your branches unique in the different timelines or you'll end up with spurious warnings about forks. For some interesting reading on the topic, see 1, 2, and 3.

These messages all mention the use of shunning and SQL trickery, but that’s not even necessary nowadays. I currently have several repositories containing multiple completely disconnected branches, that have no overlap whatsoever; simply by using fossil open --empty, and specifying a new branch on the first commit from that checkout.

Just out of curiosity, is there anyone still managing Fossil repositories like this?

I’ve been using the principle for several different reasons. (I’m not saying they are good reasons. Those were just the reasons I started using that methodology; they seemed good, or even just interesting, at the time):

  • The source code in trunk, and the release binaries in a ‘disconnected’ release branch. Fossil’s /zip URL allows me to easily publish links to either the latest release (fossil.example.com/zip/latest.zip?uuid=release), or (by using version tags) to specific releases. Works a treat!
  • Multiple attempts at making a certain tool, in completely different languages and toolsets. They have nothing in common but the end goal, so the notes containing the requirements (wiki etc.) are shared across the board. Since the different attempts are written for completely different languages and environments, no merging would ever happen between the disparate branches.
  • Multiple aspects of the same piece of software that run in different environments, like a collection of scripts, located on different servers, yet working together). It’s very handy to be able to checkout a branch on each server without getting the cruft destined for the other servers; yet all the information is located in the same repository.

The one ‘disadvantage’ of doing this, is that all these branches, disconnected though they are, all show up on the same timeline. Of course, it’s possible to limit the timeline to a specific branch, but usually, I want to see the splitting and merging branches as well, and those then get snipped as well.

So they’re not completely independent. Of course, they also share all tickets and wiki pages.

(11) By anonymous on 2019-08-22 16:46:28 in reply to 10 [link] [source]

The one ‘disadvantage’ of doing this, is that all these branches, disconnected though they are, all show up on the same timeline.

The d=CHECKINORTAG query parameter to /timeline will show the descendants of the specified check-in. If you give the original check-in of a branch, you will see just check-ins for that branch and its subbranches.

(12) By Andy Bradford (andybradford) on 2019-08-28 13:05:34 in reply to 10 [link] [source]

> I currently  have several repositories containing  multiple completely
> disconnected  branches, that  have  no overlap  whatsoever; simply  by
> using fossil  open --empty, and specifying  a new branch on  the first
> commit from that checkout.

Yes, I  had forgotten that this  option existed (or assumed  that it got
removed as some  of the other changes that were  introduced during those
discussions had been).

Thanks,

Andy