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

Reply via email to