On Tue, Jul 12, 2011 at 11:46 AM, Jeremy Anderson <[email protected]> wrote:
> I... > 1) told WinSec to ignore my fossil repository directory, > 2) disabled the "fossil server" process > 3) closed my open changelist (also on the server machine) > 4) did another rebuild with --wal (on the server) > 5) re-opened the repository (on the server) > 6) restarted the service > > fossil sync still fails with the same issue: > > Error: Database error: database is locked > DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private) > Try this: Please stop the server, then restart it with the --sqltrace option. This will give large amounts of debugging output on the console. Please redo your "pull", capture the output, and send to me via private email. Tnx! > > > On Tue, Jul 12, 2011 at 8:18 AM, Richard Hipp <[email protected]> wrote: > >> >> >> On Tue, Jul 12, 2011 at 11:09 AM, Jeremy Anderson <[email protected]>wrote: >> >>> The prior log was from a run on the server machine, but the fossil >>> "server" process was still running at the time. Would/could/should it be >>> different if I stop the "fossil server" instance as well? >>> >>> As for compilation, I haven't tried. Depending on what you need to build >>> it, I may or may not be able/willing to. :) >>> >>> As I'm sure you can relate to, disabling my AV software (i'm using >>> Windows Security Essentials) for any length of time isn't high on my >>> priority list. It's a scary place, the internet, yet I need my fossil server >>> visible from there 24x7 so I can work in a distributed manner with my >>> friend(s). I'm sure you understand. =) >>> >>> Very much appreciate fossil (huge thank you!) and the help, of course. >>> Let me know how else I can be of service. >> >> >> I'm told that with Windows Security Essentials, you can configure it to >> ignore selected directories. If you cannot completely disable the AV >> software, can you at least disable it for the one directory that contains >> your repositories? Just as a test? >> >> >>> >>> >>> On Tue, Jul 12, 2011 at 7:18 AM, Richard Hipp <[email protected]> wrote: >>> >>>> >>>> >>>> On Tue, Jul 12, 2011 at 10:10 AM, Jeremy Anderson <[email protected]>wrote: >>>> >>>>> Thanks! Let's give it as shot... >>>>> >>>>> C:\(path)>f rebuild --wal >>>>> 100.0% complete... >>>>> C:\(path)>f sync >>>>> Server: http://[user]@[domain]:[port] >>>>> 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) >>>>> >>>> >>>> Please run the "fossil rebuild --wal" on the server. I think that is >>>> where it is really going to matter the most. >>>> >>>> Also, please try disabling the antivirus software on both client and >>>> server. That might help. If you glance over at >>>> http://www.sqlite.org/src/timeline you can see that we are currently in >>>> the midst of trying to teach SQLite to work around some of the more >>>> psychopathic behavior of AV software. Once we get closure on that, I'll >>>> move the latest SQLite into Fossil and recompile. That might help too. >>>> But >>>> it will be a day or two. (Do you have the ability to compile Fossil from >>>> sources yourself - you could help beta-tst the new AV-defenses!) >>>> >>>> >>>>> Received: 118 1 0 0 >>>>> Total network traffic: 1980 bytes sent, 861 bytes received >>>>> >>>>> Doesn't appear to have. =( >>>>> >>>>> >>>>> On Tue, Jul 12, 2011 at 3:43 AM, Richard Hipp <[email protected]> wrote: >>>>> >>>>>> On Mon, Jul 11, 2011 at 9: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. >>>>>>> Error: Database error: database is locked >>>>>>> DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private) >>>>>>> >>>>>>> Anyone have a workaround? >>>>>>> >>>>>>> >>>>>> >>>>>> Please try running: >>>>>> >>>>>> fossil rebuild --wal >>>>>> >>>>>> Let me know if that clears the issue for you. >>>>>> >>>>>> >>>>>> -- >>>>>> D. Richard Hipp >>>>>> [email protected] >>>>>> >>>>>> _______________________________________________ >>>>>> fossil-users mailing list >>>>>> [email protected] >>>>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> fossil-users mailing list >>>>> [email protected] >>>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>>>> >>>>> >>>> >>>> >>>> -- >>>> D. Richard Hipp >>>> [email protected] >>>> >>>> _______________________________________________ >>>> fossil-users mailing list >>>> [email protected] >>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>>> >>>> >>> >>> _______________________________________________ >>> fossil-users mailing list >>> [email protected] >>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>> >>> >> >> >> -- >> D. Richard Hipp >> [email protected] >> >> _______________________________________________ >> fossil-users mailing list >> [email protected] >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> >> > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
