Re: [fossil-users] cloning / opening fails on WinXP SP3

On Fri, Jun 21, 2013 at 9:25 PM, Edward Berner wrote: > > I think recv() was biting off more than it could chew. > > Here is the workaround: >while( N>0 ){ > -got = recv(iSocket, pContent, N, 0); > +got = recv(iSocket, pContent, N>20 ? 20 : N, 0); > if( got<=0 ) break; >

Re: [fossil-users] cloning / opening fails on WinXP SP3

On 6/21/2013 3:29 PM, Edward Berner wrote: I think I figured out part of the problem. Way down in http_socket.c, there is no error handling in socket_receive() and socket_send(). In socket_receive(), I'm seeing a -1 return from recv(), and WSAGetLastError() returns 10055 which is WSAENOBUFS.

Re: [fossil-users] cloning / opening fails on WinXP SP3

On 6/19/2013 1:25 AM, Edward Berner wrote: On 6/18/2013 7:56 PM, Richard Hipp wrote: On Tue, Jun 18, 2013 at 10:52 PM, Edward Berner > wrote: I was able to reproduce a similar behavior, and I think it has to do with the size of those files. I created

Re: [fossil-users] RFC: new config option

On Fri, Jun 21, 2013 at 9:42 PM, Edward Berner wrote: > But... what about per-user script hooks? > This would certainly be a perfect use case for them. i can't speak to the security concerns. On a related note, there is a precedence for such an option: mysql client does not allow UPDATE given o

Re: [fossil-users] RFC: new config option

On 6/21/2013 9:32 AM, Stephan Beal wrote: Hiho, In a repo of mine (not fossil) i just made a commit faux pas by not entering the _one_ filename i wanted on the command line, and instead committing several others i wasn't ready to commit. So now i want to add a fossil feature but thought i'd r

Re: [fossil-users] RFC: new config option

On Fri, Jun 21, 2013 at 8:01 PM, Richard Hipp wrote: > An "uncommit" command has been on the to-do list for a long time, but has > not yet been implemented. > And i've only missed it once or twice - i know this is a corner case and impossible when syncing is on. > Note that "uncommit" is consi

Re: [fossil-users] RFC: new config option

On Jun 21, 2013 11:02 AM, "Richard Hipp" wrote: > > > > On Fri, Jun 21, 2013 at 1:35 PM, B Harder wrote: >> >> I realize this check is early in the commit phase, but now I wonder: barring pushed/autosync'd content, can one "pop" or unwind the last commit of a local repo? >> >> > > An "uncommit" c

Re: [fossil-users] RFC: new config option

On Fri, Jun 21, 2013 at 1:35 PM, B Harder wrote: > I realize this check is early in the commit phase, but now I wonder: > barring pushed/autosync'd content, can one "pop" or unwind the last commit > of a local repo? > > > An "uncommit" command has been on the to-do list for a long time, but has n

Re: [fossil-users] RFC: new config option

On Jun 21, 2013 9:32 AM, "Stephan Beal" wrote: > > Hiho, > > In a repo of mine (not fossil) i just made a commit faux pas by not entering the _one_ filename i wanted on the command line, and instead committing several others i wasn't ready to commit. So now i want to add a fossil feature but thoug

[fossil-users] RFC: new config option

Hiho, In a repo of mine (not fossil) i just made a commit faux pas by not entering the _one_ filename i wanted on the command line, and instead committing several others i wasn't ready to commit. So now i want to add a fossil feature but thought i'd run it through the crowd for opinions or alterna

Re: [fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree

2013/6/21 Stephan Beal : > On Fri, Jun 21, 2013 at 3:57 PM, Richard Hipp wrote: >> >> I've already been working on the problem for 10 minutes. Implemented "fossil changes" and "fossil status" now, which is much simpler. It took me 25 minutes Regards, Jan Nijtmans

Re: [fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree

On Fri, Jun 21, 2013 at 3:57 PM, Richard Hipp wrote: > I've already been working on the problem for 10 minutes. Okay, we'll take your word for it! ;) > I think that means you owe me a weissbier the next time I'm in München! > Duly noted! -- - stephan beal http://wanderinghorse.net/ho

Re: [fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree

On Fri, Jun 21, 2013 at 9:54 AM, Stephan Beal wrote: > On Fri, Jun 21, 2013 at 3:43 PM, Jan Nijtmans wrote: > >> That will no longer be true.. Richard can do that in 5 minutes, but >> for everyone else it will take much longer ;-) >> > > i'll bet 5 Euros that he could do it in THREE minutes

Re: [fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree

On Fri, Jun 21, 2013 at 3:43 PM, Jan Nijtmans wrote: > That will no longer be true.. Richard can do that in 5 minutes, but > for everyone else it will take much longer ;-) > i'll bet 5 Euros that he could do it in THREE minutes ;) -- - stephan beal http://wanderinghorse.net/home/stepha

Re: [fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree

2013/6/21 j. van den hoff : > just a thought: a somehow related feature would be the ability to do > something like > > fossil ci {dirname} Yes, that would be consistant with "fossil clean|extras|ls" to allow that, but it's not completely trivial. The query that should be modified is here:

Re: [fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree

just a thought: a somehow related feature would be the ability to do something like fossil ci {dirname} where {dirname} is one of the directories found in the checkout which then should restrict the ci to everything recursively found in {dirname} and below. personally I don't miss such a f

Re: [fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree

Le 21 juin 2013 04:35, "Jan Nijtmans" a écrit : > > 2013/6/20 Stephan Beal : > > Any chance of adding the same to "ls" as well? > > Hm.. > > $ ./fossil ls win/include > win/include/dirent.h > win/include/unistd.h > $ rm -rf win/include;fossil status > > MISSINGwin/include/dirent.h > MISSI

Re: [fossil-users] Ticket [967cedbf20]: fossil extra - Report for subtree

2013/6/20 Stephan Beal : > Any chance of adding the same to "ls" as well? Hm.. $ ./fossil ls win/include win/include/dirent.h win/include/unistd.h $ rm -rf win/include;fossil status MISSINGwin/include/dirent.h MISSINGwin/include/unistd.h $ ./fossil ls win/include $ Even if the file

Re: [fossil-users] 64 bit rowid bug?

>But i'm just being technically pedantic, so don't take all that too seriously. >i see nothing wrong with using sqlite3_int64 everywhere, to be honest, and >wouldn't mind adding a patch to the upstream JSON bits which use >>sqlite3_int64 when compiling for fossil (they already have one such plac