On Wed, Apr 1, 2015 at 6:55 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:
> On 4/1/2015 3:21 AM, Vikrant Chaudhary wrote:
> >> I'm thinking about how this could be used at my workplace. On some
> >> projects we have shared computers called viewservers ("view" being a
> >> ClearCase term) on which we create our sandboxes (again, CC term).
> >> Switching to Fossil would mean each user getting his or her own copy of
> >> the full repository which synchronizes with the master. Furthermore,
> >> each user would need a separate copy for each viewserver because it's
> >> best not to share SQLite databases through NFS. This will eat a LOT of
> >> disk space.
>
I'm supporting a group with over 500 fossils, hundreds of checkins per day.
All on NFS. There have been issues but few due to NFS locking. The central
files are accessed via ssh.
I do wish fossil supported a model where multiple users could do fossil
open off of a single fossil db. The distributed quality of fossil is the
feature we leverage least and the feature that causes the most issues
(forks are very confusing for casual users of fossil).
> >>
> >> If users could somehow share repositories without copying them in full,
> >> that would help a lot.
> >
> > You are probably thinking about a "shallow clone".
>
> You'll have to tell me what you mean by those words.
>
> > By "clone --cheap", I was thinking more along the lines of "ATTACH
> > DATABASE". I.e., collecting missing deltas from upstream db which is
> > attached to main db. Which also means that upstream repository must
> > exist on file-system (no http).
>
> The impression I get is that we're both talking about the local
> repository containing things not sync'ed upstream, for example private
> branches.
>
I see clone --cheap as being about keeping most of the blobs in a central
fossil and having a side sqlite db that contains only the extra blobs as
committed to the cheap clone. You see the entire clone by ATTACHING the two
dbs. I'm not saying this implementation idea would work (although I suspect
it might) - only that it illustrates the principle being sought after.
>
> > Truth is, I need to understand more about Fossil internals to make any
> > assertions on what is possible and what is not.
>
> This is a dramatic departure from the current design of Fossil which
> directly opens the repository file, which is an SQLite database. What
> you suggest would require frequent communication with the repository at
> the remote-url for doing many kinds of read operations.
>
> --
> Andy Goth | <andrew.m.goth/at/gmail/dot/com>
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
