Re: [fossil-users] fsl gdiff prevents commit in parallel.
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 details. I'm using fossil version 1.25. >> >> > Yes. You need a Tcl/Tk interpreter installed on your system. I suggest > downloading one from ActiveState.com > http://www.activestate.com/activetcl/downloads > Is that the "wish" command? I have 8.4.1 on the path. Is there anything else I might have missed? > wish % info patchlevel 8.4.1 > -- > D. Richard Hipp > d...@sqlite.org > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fsl gdiff prevents commit in parallel.
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 interpreter installed on your system. I suggest downloading one from ActiveState.com http://www.activestate.com/activetcl/downloads -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fsl gdiff prevents commit in parallel.
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 of the actual locked database to the error >> message would help a lot. >> >> > 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 has not been fixed is that I never used "gdiff" myself and so > have not noticed the problem. > "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. Thanks > -- > D. Richard Hipp > d...@sqlite.org > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fsl gdiff prevents commit in parallel.
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 has not been fixed is that I never used "gdiff" myself and so > have not noticed the problem. > Please let us know if you fix this, otherwise i'll take a look at it in the next 20 hours or so. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fsl gdiff prevents commit in parallel.
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 lot. > > 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 has not been fixed is that I never used "gdiff" myself and so have not noticed the problem. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fsl gdiff prevents commit in parallel.
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 ;). If it can, it can provide a better error message. Db's > 1. _FOSSIL_ or .fslckout > 2. ~/.fossil > 3. The private repo db (testing.fossil in my example) > Theoretically all of the above could be locked at any one time. > Possible causes of db "Locked" > 1. disk or partition full or over quota > sqlite3 doesn't recognize this level of error. An i/o error should not, AFAIK, cause a locking condition, though. The erroring process would (presumably) exit or return to a point where they close the DB. 2. some previous operation crashed > A crash should release a lock immediately. That's handled by the OS. > 3. db open by some operation > In which case a lock error is expected/correct. > 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 lot. > It might not be difficult - we could probably just close the db explicitly after processing the diff. It's too late tonight, but i'll take a look at it tomorrow evening. Keep the feedback coming, and Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fsl gdiff prevents commit in parallel.
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 repo db (testing.fossil in my example)
Possible causes of db "Locked"
1. disk or partition full or over quota
2. some previous operation crashed
3. db open by some operation
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 lot.
On Wed, Jul 3, 2013 at 2:11 PM, Stephan Beal wrote:
> 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 "rebuild noise" added later on (i don't think that part
> recognizes specific error codes, but i'll add this to the TODO list).
>
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
--
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fsl gdiff prevents commit in parallel.
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 "rebuild noise" added later on (i don't think that part recognizes
specific error codes, but i'll add this to the TODO list).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fsl gdiff prevents commit in parallel.
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 Artifacts sent: 0 received: 0
Pull finished with 267 bytes sent, 1585 bytes received
fossil: database is locked: {COMMIT}
If you have recently updated your fossil executable, you might
need to run "fossil all rebuild" to bring the repository
schemas up to date.
==
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?
--
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] File mode information loss following a merge
I was able to reproduce this aswell with the following setup: Linux aramaki 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux This is fossil version 1.26 [07463fbf02] 2013-06-29 15:41:28 UTC On Mon, Jul 1, 2013 at 10:00 PM, Marc Simpson wrote: > Hi all, > > I've just encountered a scenario in which file mode information is lost > following a merge. This involves (a) adding an executable file, (b) > renaming it in a branch, then (c) merging back into trunk. > > To replicate, > > $ repo=tmp > $ fossil new $repo.fsl; mkdir $repo; cd $repo > $ fossil open ../$repo.fsl > $ touch a; chmod +x a > $ fossil add a; fossil commit -m "Add 'a'" > $ mv a b > $ fossil mv a b > $ fossil commit -m "Rename 'a' to 'b'" --branch moved > $ fossil up trunk > $ fossil merge moved > $ fossil commit -m 'Merge moved.' > > Note that 'b' is executable in 'moved' but not in 'trunk'. > > (Encountered on Linux, recreated on OS X with the latest Fossil build.) > > Best, > Marc > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
