On Thu, Jul 4, 2013 at 4:11 PM, Stephan Beal wrote:
> Here's my proposed patch, but i'm not at all sure if this is the proper
> fix:
>
Nevermind - only certain ops run w/o the lock error with this change. An
update still fails.
Back to the drawing board...
--
- stephan beal
http://wanderi
On Wed, Jul 3, 2013 at 11:53 PM, Stephan Beal wrote:
> On Wed, Jul 3, 2013 at 11:50 PM, Richard Hipp wrote:
>
>> I agree, "fossil gdiff" should not keep the database locked. FWIW, the
>> "fossil diff --tk" command does not keep the database locked, at least not
>> that I have noticed. If "foss
On Wed, Jul 3, 2013 at 3:13 PM, Richard Hipp wrote:
>
>
> On Wed, Jul 3, 2013 at 6:07 PM, Matt Welland wrote:
>
>>
>> "fossil diff --tk" exits instantly with exit code 0 on my system. Is
>> there setup necessary to use this? I dug though the help and mailing list
>> and didn't run across any det
On Wed, Jul 3, 2013 at 6:07 PM, Matt Welland wrote:
>
> "fossil diff --tk" exits instantly with exit code 0 on my system. Is there
> setup necessary to use this? I dug though the help and mailing list and
> didn't run across any details. I'm using fossil version 1.25.
>
>
Yes. You need a Tcl/Tk
On Wed, Jul 3, 2013 at 2:50 PM, Richard Hipp wrote:
>
>
> On Wed, Jul 3, 2013 at 5:42 PM, Matt Welland wrote:
>
>>
>> I still feel that ideally "fossil gdiff" should not tie up the database
>> and prevent commits but I understand that may not be easy to fix. However
>> adding the full file name
On Wed, Jul 3, 2013 at 11:50 PM, Richard Hipp wrote:
> I agree, "fossil gdiff" should not keep the database locked. FWIW, the
> "fossil diff --tk" command does not keep the database locked, at least not
> that I have noticed. If "fossil gdiff" is locking the database, probably
> the reason it h
On Wed, Jul 3, 2013 at 5:42 PM, Matt Welland wrote:
>
> I still feel that ideally "fossil gdiff" should not tie up the database
> and prevent commits but I understand that may not be easy to fix. However
> adding the full file name of the actual locked database to the error
> message would help a
On Wed, Jul 3, 2013 at 11:42 PM, Matt Welland wrote:
> Thanks Stephan. What solution did you plan to add to the TODO list?
>
To see if the place where it says "rebuild..." can see the error code from
the lock (i think that happens a couple functions away, and i'm too tired
to search for it ;). I
Thanks Stephan. What solution did you plan to add to the TODO list?
Note that the "is locked" was noticed but there are three possible sqlite3
databases that might be the issue and there are several possible ways that
a db can be locked:
Db's
1. _FOSSIL_ or .fslckout
2. ~/.fossil
3. The private r
On Wed, Jul 3, 2013 at 11:09 PM, Matt Welland wrote:
> fossil: database is locked: {COMMIT}
> If the database cannot be freed up during the diff then how about some
> hint to the user as to what might be going on?
>
The "is locked" part is the hint, but it's unfortunately well hidden within
the
I've run into this a few times now and it is annoying, mostly because it is
very difficult to figure out *why* you can't commit.
==
fossil gdiff &
fossl commit -m "just testing"
EDITED nada.txt
Autosync: file:///p/foundry/env/repo/fossil/fdk/testing.fossil
Round-trips: 1 Artifac
11 matches
Mail list logo
