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 place so that they use fossil_alloc() and fossil_free(), to inherit its die-on-alloc-failure behaviour, which reduces (greatly) the amount of error checking in the fossil JSON bits). Well, looking at the fossil code, int's are use everywhere, except for timestamps and file sizes. I think that would be a good rule for JSON as well. A few related fixes: https://www.fossil-scm.org/index.html/info/f89a32d782 This way, files somewhat bigger than 2Gb or timestamps after 2038 wouldn't be an immediate problem. But transfering a 64-bit pointer or a 64-bit hash value as an integer on JSON, that's asking for trouble! Regards, Jan Nijtmans ___ 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] Ticket [967cedbf20]: fossil extra - Report for subtree
2013/6/20 Stephan Beal sgb...@googlemail.com: 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 files are missing locally, they are still in the repository so they should be listed. Fixed now: https://www.fossil-scm.org/index.html/info/c0b98195f9 (query borrowed from fossil delete/mv) fossil changes and fossil status still to be done ;-) Regards, Jan Nijtmans ___ 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] 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 feature at all but I discovered that
svn users expect the `ci' action to be restricted to the sub-directory
they are currently in and don't like that things further up in the
directory tree are also included. some have strong feelings about svn's
behavior being good while fossils behavior (and hg's and ...) to ci
everything is considered bad. I don't share this opinion, but if one
could tell them OK, then cd to your desired subdirectory and do `fossil
ci .' might make them happy.
j.
On Fri, 21 Jun 2013 10:35:46 +0200, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2013/6/20 Stephan Beal sgb...@googlemail.com:
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 files are missing locally, they are still in
the repository so they should be listed. Fixed now:
https://www.fossil-scm.org/index.html/info/c0b98195f9
(query borrowed from fossil delete/mv)
fossil changes and fossil status still to be done ;-)
Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] Ticket [967cedbf20]: fossil extra - Report for subtree
2013/6/21 j. van den hoff veedeeh...@googlemail.com:
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:
https://www.fossil-scm.org/index.html/artifact/087b517034?ln=730
but a few lines earlier an explicit array is allocated which expects the
number of id's to be less than the number of command line arguments.
That will no longer be true.. Richard can do that in 5 minutes, but
for everyone else it will take much longer ;-)
Regards,
Jan Nijtmans
___
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] Ticket [967cedbf20]: fossil extra - Report for subtree
On Fri, Jun 21, 2013 at 3:43 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 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/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] Ticket [967cedbf20]: fossil extra - Report for subtree
On Fri, Jun 21, 2013 at 9:54 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Jun 21, 2013 at 3:43 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 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 ;) I've already been working on the problem for 10 minutes. I think that means you owe me a weissbier the next time I'm in München! -- - 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 -- 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] Ticket [967cedbf20]: fossil extra - Report for subtree
On Fri, Jun 21, 2013 at 3:57 PM, Richard Hipp d...@sqlite.org 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/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] Ticket [967cedbf20]: fossil extra - Report for subtree
2013/6/21 Stephan Beal sgb...@googlemail.com: On Fri, Jun 21, 2013 at 3:57 PM, Richard Hipp d...@sqlite.org 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[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 alternatives before i code a feature of out frustration ;). The hypothetical usage and effect would look like this: $ fossil config set empty-commit-warn $ fossil commit -m '...' No file names provided. Really continue? [y/N] The warning would only show if empty-commit-warn (or whatever name we chose) is on, of course (default=off). :-? -- - 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] RFC: new config option
On Jun 21, 2013 9:32 AM, Stephan Beal sgb...@googlemail.com 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 run it through the crowd for opinions or alternatives before i code a feature of out frustration ;). The hypothetical usage and effect would look like this: $ fossil config set empty-commit-warn $ fossil commit -m '...' No file names provided. Really continue? [y/N] 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? The warning would only show if empty-commit-warn (or whatever name we chose) is on, of course (default=off). :-? -- - 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] RFC: new config option
On Fri, Jun 21, 2013 at 1:35 PM, B Harder brad.har...@gmail.com 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 not yet been implemented. Note that uncommit is considerably less useful in Fossil compared to Git, since Fossil normally has autosync turned on so that your content gets pushed automatically right after the commit in most cases. And everybody agrees that uncommit is not feasible once you have pushed. When you want to undo a check-in in Fossil, the typical procedure is to move that check-in off into a dead-end branch named error or mistake. Example here: http://www.fossil-scm.org/fossil/timeline?n=8c=2011-06-16+18:10:54y=ci VCSes that have an uncommit command allows one to airbrush out embarrassing missteps. Fossil, on the other hand, forces us to own up to our errors. Fossil: Encouraging confession, penitence, and humility since 2007 ;-) -- 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] RFC: new config option
On Jun 21, 2013 11:02 AM, Richard Hipp d...@sqlite.org wrote: On Fri, Jun 21, 2013 at 1:35 PM, B Harder brad.har...@gmail.com 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 not yet been implemented. Note that uncommit is considerably less useful in Fossil compared to Git, since Fossil normally has autosync turned on so that your content gets pushed automatically right after the commit in most cases. And everybody agrees that uncommit is not feasible once you have pushed. Re: not feasible once pushed - that is understood. Whether an uncommit would be considerably less useful is not clear to me though. I too have made accidental commits where I'm working on a feature, and go on a slight tangent, or have stray un-stashed work and end up committing more than I want. I usually just end up amending the commit msg. I fossilize the vast majority of my personal work, which isn't collaborative, and not autosync'd. I'd be surprised if there aren't many more like me. I suspect it's the nature of this sort of work that we don't hear about it because it's small and personal, versus a big public fossil projects like Tcl or SQLite. If the discussion is all about big projects and how to utilize fossil, autosync is arguably a smart option. I'm a little curious what thelong tail of fossil projects looks like. I can say for *my* work though, I'd get value out of an uncommit command. When you want to undo a check-in in Fossil, the typical procedure is to move that check-in off into a dead-end branch named error or mistake. Example here: http://www.fossil-scm.org/fossil/timeline?n=8c=2011-06-16+18:10:54y=ci VCSes that have an uncommit command allows one to airbrush out embarrassing missteps. Fossil, on the other hand, forces us to own up to our errors. Fossil: Encouraging confession, penitence, and humility since 2007 ;-) I completely agree and appreciate this, but I think making an exception for the undistributed TIP commit isn't too offensive to the spirit. -- 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 ___ 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] RFC: new config option
On Fri, Jun 21, 2013 at 8:01 PM, Richard Hipp d...@sqlite.org 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 considerably less useful in Fossil compared to Git, since Fossil normally has autosync turned on so that your content gets pushed automatically right after the commit in most cases. And everybody agrees that uncommit is not feasible once you have pushed. i had, incidentally, turned off autosync by accident because i thought that two 'opens' of the same repo did not share that setting (i have a test copy which i don't want to autosync, but i just realized 4 minutes ago that they share that setting). So in this once in a million case i could have used an uncommit, but autosync is normally always on. So IMO it's not worth the implementation hassle (it wouldn't/couldn't help me very often, in any case). -- - 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] 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 run it through the crowd for opinions or alternatives before i code a feature of out frustration ;). The hypothetical usage and effect would look like this: $ fossil config set empty-commit-warn $ fossil commit -m '...' No file names provided. Really continue? [y/N] The warning would only show if empty-commit-warn (or whatever name we chose) is on, of course (default=off). How about a pre-commit script? Maybe in TH1 or TCL or run-a-local-program, etc. I know the general case of script hooks has been discussed before and there are difficulties due to the distributed nature of things, not to mention security and portability concerns. But... what about per-user script hooks? I don't know if that has been discussed. They'd live in ~/.fossil and hopefully avoid the complications of the general case. I'd envision the scripts as applying to all repositories, but giving the script access to the project-id so it could limit itself to certain repositories if desired. One drawback is that you'd have to setup your scripts by hand on each system you develop on. Just a thought. -- Edward Berner ___ 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] RFC: new config option
On Fri, Jun 21, 2013 at 9:42 PM, Edward Berner e...@bernerfam.com 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 on the command line without a WHERE clause unless you specify a certain other option: [stephan@host:~/cvs/fossil/cwal/th1ish]$ mysql --help | grep dummy -U, --i-am-a-dummy Synonym for option --safe-updates, -U. i-am-a-dummy FALSE But adding --i-am-a-dummy to allow no-file-name commits in fossil would be backwards-incompatible ;). -- - 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] 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 e...@bernerfam.com mailto:e...@bernerfam.com wrote: I was able to reproduce a similar behavior, and I think it has to do with the size of those files. I created a 200 MB file and a 150 MB file using dd from /dev/arandom. I added those to a new repository on an OpenBSD system and was able to successfully clone it to a CentOS Linux system but it did not successfully clone to a Windows XP SP3 system. I was able to clone from Linux to Win8 successfully. Do you think it is some kind of XP-specific problem? I'm surprised, but yeah, its looking that way. I just ran the test again using the same fossil binary on XP and Windows 7. The clone failed on XP but succeeded on (64 bit) Windows 7. It also succeeds on 32 bit Vista but fails on Windows 2000 (I had to use a different binary on Windows 2000). As a sanity check I served up a copy of Fossil's own repository in the same way as my test repository. All systems were able to successfully clone it. 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. According to the MSDN Library that means No buffer space available. An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. (I don't know yet what the WSAENOBUFS is about or how to avoid or handle it) -- Edward Berner ___ 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] 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. According to the
MSDN Library that means No buffer space available. An operation on a
socket could not be performed because the system lacked sufficient
buffer space or because a queue was full.
(I don't know yet what the WSAENOBUFS is about or how to avoid or
handle it)
I think recv() was biting off more than it could chew.
Here is the workaround:
Index: src/http_socket.c
==
--- src/http_socket.c
+++ src/http_socket.c
@@ -200,13 +200,13 @@
*/
size_t socket_receive(void *NotUsed, void *pContent, size_t N){
ssize_t got;
size_t total = 0;
while( N0 ){
-got = recv(iSocket, pContent, N, 0);
+got = recv(iSocket, pContent, N20 ? 20 : N, 0);
if( got=0 ) break;
total += (size_t)got;
N -= (size_t)got;
pContent = (void*)((char*)pContent)[got];
}
return total;
}
I say workaround instead of fix because I've only tested it on two
platforms (Windows 2000 and Windows XP SP3) and because that arbitrary
magic number looks kinda ugly.
--
Edward Berner
___
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] cloning / opening fails on WinXP SP3
On Fri, Jun 21, 2013 at 9:25 PM, Edward Berner e...@bernerfam.com wrote:
I think recv() was biting off more than it could chew.
Here is the workaround:
while( N0 ){
-got = recv(iSocket, pContent, N, 0);
+got = recv(iSocket, pContent, N20 ? 20 : N, 0);
if( got=0 ) break;
Thanks for the patch. I've checked in something similar to the Fossil
trunk.
--
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
