So, you are saying it is possible for multiple, independant Fossil clients to share a single repository?
I had assumed that Fossil had some internal signaling mechanism to allow command line invocations while "fossil ui" (or fossil server") was running - not unlike how you can enter "firefox example.com" and the page will be opened in the existing browser instance, rather than launching another browser instance. One of the reasons we are looking at Fossil for issue tracking (and are using Git for source VCS) is that no central server is required. (Of course, one of the problems with running purely peer-to-peer is the need tp pull/push between multiple PCs. That is not much of problem with VCS within the software group, But with issue tracking - especially when deployed beyond the software group - these pull/push operations need to be fully automated. If Fossil can operate with a shared repository, this might be a better solution than trying to automate multi-way pull/push operations. (If anyone is curious, within the software group, we are free to manage our tools as we need - as long as our tools use only our PCs and only use IT servers for file service. To run a server on an IT server PC requires approval from both the CIO and CFO.) On Mon, Jan 31, 2011 at 10:23 AM, Richard Hipp <d...@sqlite.org> wrote: > Posix advisory locking tends to give problems on many NFS implementations. > You can cause Fossil to use dot-file locking instead by setting an > environment variable: > > export FOSSIL_VFS=unix-dotfile > > That might fix your problem. Caution, though: If you have two different > copies of Fossil running and one is using dotfile locking and the other > posix advisory locking, then they might step on one another and corrupt the > database! So if you use FOSSIL_VFS, make sure you use it consistently! _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
