On 8/15/2014 14:37, Charles Curtit wrote:
Can a server handle fsyncs
from multiple peers at the same time ?
Careful with your terminology. "fsync" may mean the POSIX syscall
fsync(), but from context, I think you're actually talking about "fossil
sync" here.
It's doubly confusing because SQLite relies pretty heavily on fsync()
and similar APIs on the OSes it runs on.
If you're asking what happens when multiple satellite offices try to
sync their repos with the central one at the same time, they're handled
one at a time, in FIFO fashion, since everything is wrapped in a SQL
transaction; SQLite will not allow the same table row to be modified
literally at the same time by two different clients. See:
https://www.sqlite.org/lockingv3.html
Each sync is atomic: all the changes are accepted, or none of them are.
If the central server's copy gets changed in a way that makes any of
the satellites incapable of syncing without help, you either have to do
a manual merge, or you create a fork. See:
http://www.fossil-scm.org/xfer/doc/tip/www/branching.wiki
If two sites edit the same file in *different places*, Fossil can
usually merge the two change sets automatically. It certainly happens
in source code type files, which is Fossil's forte.
Automatic merge cannot happen with binary files or anything sufficiently
like a binary file. Some XML-based file formats aren't especially
well-designed from a version control standpoint, for example, in that a
small change in one place can ripple across the entire file.
Automatic merge also doesn't happen with Fossil's wiki; see below.
is it
possible in the interface to sort tickets by branches/tags sort of easily ?
The ticket system lets you define custom reports, so you could have one
that shows just one satellite office's tickets. You can make it do
anything SQL and TH1 together can achieve, which is a lot.
Is it also possible to have branches on the wiki ?
Technically, yes, but there is no way to browse the branching history
for wiki pages in the current Fossil UI.
Even more significant, such branching occurs silently and automatically
if two satellite offices sync a change to the same wiki document.
In Fossil's more normal use case, managing individual files (e.g. source
code), Fossil will try to do an automatic merge, and will offer a choice
of a manual merge or an automatic fork if it cannot merge the two change
sets automatically. Fossil's wiki system cannot do this yet, according to:
http://www.fossil-scm.org/index.html/doc/trunk/www/wikitheory.wiki
So, you won't want to use Fossil wiki pages as a substitute for a
collaborative word processor.
By contrast, storing your "word processing" documents as files in
Markdown format *would* probably be practical, since changes do not
generally ripple through the entire document with Markdown. Fossil can
show Markdown documents in the GUI via the doc URL feature:
http://fossil-scm.org/index.html/doc/trunk/www/embeddeddoc.wiki
You can link to such documents from the wiki, but you won't be able to
use the wiki's WYSIWYG editing features to change them.
That said, there are a bunch of Markdown editors for all platforms now,
with varying levels of WYSIWYGness. Some are just Markdown-aware text
editors, not really WYSIWYG at all, but using syntax highlighting and
such to hint at the effect of your changes to the document. The other
extreme are basically word processors that happen to store the document
in Markdown format. Then there are the programs that try to split the
difference, showing the raw Markdown and the formatted version side by side.
How are user accounts managed ? per server I’d imagine ? Can you walk me
thru what happens once a user has been created on a server, the next
time fsync is run ? How do user rights tie into this ?
http://fossil-scm.org/index.html/doc/trunk/www/password.wiki
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
