A friend of mine and I have started using Fossil for our scm needs. Happy
with it conceptually, but very frustrated with the persistant, nagging
connectivity issues we are having.
*Version:*
This is fossil version [0448438c56] 2011-05-28 18:51:22 UTC
*Topology:*
I have 2 Windows 7 64bit machines, and my friend has 2 as well. I'll make up
some names and tell you what they do:
1) "jer-dev" which runs "fossil server" on a custom port and acts as our
"always-available" repository for syncing our changes to/from.
* It runs this as a service via "NSSM" so it's always-there, even when
i'm not logged in.
* * Note: The problems i'm going to describe happen whether or not
it's hosted by NSSM.* They were happening before, and running as a service
hasn't improved or degraded matters any.
* My router is configured to forward all requests for the fossil port
to jer-dev inside the firewall, which is also configured to allow incoming
requests to fossil. *When* it works, it works fine.
2) "jer-laptop" which is a laptop that cloned its depot from executor over
http.
3) "rich-dev" which is his dev machine at his house, and cloned its depot
from executor over http.
4) "rich-laptop" which is his laptop that cloned its depot from executor
over http.
*Problems:*
*Scenario A: Syncing from a remote machine*
Suppose I make some changes on "jer-laptop" (or he on "rich-dev" or
"rich-laptop") and want to sync them to the server. Autosync *almost always
*fails because it says "waiting for server..." and then "cannot connect to
host". A subsequent "fossil sync" almost always works. Yet another "fossil
sync" right afterward almost never works. It seems the fossil server can
only handle one sync every minute or so, and even then it's a crapshoot. The
first one after hours or moments of inactivity might time out, or might work
fine.
*Scenario B: Syncing from the same machine as the "server"*
Suppose I make some changes on "jer-dev" and want to commit them. Recall
that jer-dev also has the instance of fossil running "fossil
server". Sometimes, I get this odd error (or one similar about the "database
is locked"):
C:\path_to_source_tree>fossil sync
Server: http://[email protected]:1234
Bytes Cards Artifacts Deltas
Sent: 3269 69 0 0
Error: Database error: database is locked
DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private)
Received: 118 1 0 0
Total network traffic: 1981 bytes sent, 861 bytes received
However, this error can appear even when the "fossil server" is not running,
but I never get it on any of the "cloned" machines. It seems to *start* when
I try to do a "local" commit on the server machine, and persists even after
I stop the "server".
Both of these issues (Scenario A and B) are very frustrating. I want to
develop locally on the machine that is also hosting the server, but fossil
to be fraught with these problems.
Fossil rebuild doesn't help get rid of this error (it always succeeds, but
doesn't fix anything).
*Bug Regression: diff/editor/gdiff settings don't support paths with spaces*
This issue appears to have regressed in version 0448438c56. If i provide a
path with spaces as the editor (e.g. "C:\Program Files\editor\editor.exe"),
I get a failure on commit that says something like "'C:\Program' is not
recognized as an internal or external command..."
8d073be8802009-09-14 19:50:27Code_DefectFixed diff/editor/gdiff settings
don't support paths with spaces
Anyone else out there encountering these or similar issues?
Anyone have a workaround?
-jer
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
