Good thoughts. I'm not using Cygwin (this is straight Windows command line stuff), but I'll locate my fossil stuff outside of the Google Drive tree and backup into it (maybe a windows cron utility - though I have to look into that).
I had to remove my local repo and clone off the remote, but that worked like a charm. Thanks for the help! Richard On Fri, Jan 9, 2015 at 11:28 PM, Warren Young <[email protected]> wrote: > On Jan 9, 2015, at 6:51 PM, Richard Boehme <[email protected]> wrote: > > > I host elsewhere - a private sever (Linode). I'm the only one who > accesses that Google Drive folder, so it's unlikely to be updated by anyone > else. > > Wrong. There are two things that can access it at once: the Google Drive > background updater, and fossil.exe. > > How can this happen, you ask? Because you’re using Cygwin Fossil: > > > C:\Users\rboehme\Google > Drive\user\Richard\Projects\CSharp\ShardGalaxy>fossil version > > This is fossil version 1.29 [3e5ebe2b90] 2014-06-12 17:25:56 UTC > > > The thing about Cygwin SQLite — which Cygwin fossil uses — is that it > defaults to BSD advisory locks, so that it will cooperate properly with > other Cygwin programs which are expecting advisory locking semantics. > > Native Windows programs, though, expect mandatory locking semantics. If > the background Google Drive updater tries updating one of the two (!) > SQLite DB files while fossil.exe is trying to update it, Windows won’t stop > it. > > The obvious SQLite DB file is the one you get from “fossil clone” but even > if you’re cloning outside the GDrive tree, you also get a _FOSSIL_ SQLite > DB file at the root of a “fossil open” tree on Windows. > > Back when I was maintaining Cygwin SQLite, you could make it use native > mandatory locks by setting a certain environment variable, but when Jan > Nijtmans took over, he changed it to use SQLite’s VFS mechanism instead. I > don’t know how to make Fossil use a different SQLite VFS. > > While it would be nice to know how to do that, I’d recommend not putting > any actively-used Fossil files in your GDrive tree. Not only do you put > the precious _FOSSIL_ DB file there, your build system probably also puts > all the build products (*.obj, *.dll, *.exe, *.pdb…) there, too. > > If you want the Fossil repo backed up to the Google Cloud, I’d “fossil > clone” and “fossil open” outside that tree, then back it up to your GDrive > as a separate step. > > Since you’re using Cygwin anyway, you can create a crontab entry that does > something like this: > > sqlite3 myrepo.fossil .dump | xz > ~/GDrive/myrepo.sql.xz > > You should get a tiny bit better compression this way, too. > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Thank you. Richard Boehme Email: [email protected] Phone: 443-739-8502 Work Phone: 410-966-6606 (Mon - Thu 6 AM - 4:30 PM)
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
