(fixing typos) On Mon, Jul 11, 2011 at 6:36 PM, Jeremy Anderson <[email protected]> wrote:
> 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 jer-dev over > http. > > 3) "rich-dev" which is his dev machine at his house, and cloned its depot > from jer-dev over http. > > 4) "rich-laptop" which is his laptop that cloned its depot from jer-dev > 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:27 Code_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
