Re: [fossil-users] [sqlite] Mailing list shutting down...
> Le 14 juin 2018 à 22:47, Warren Young a écrit : > >> having to have browser tabs open for dozens of web forums > > I bookmark all of the sites I need to go to regularly and place them in a > folder in my browser’s bookmark bar so that I can open them all at once with > a Cmd- or Ctrl-Click on the folder. As I read each forum, I close that tab. > > I actually keep two such folders, “Daily” and “Weekly,” suggesting my > visiting frequency, which is set by how often I expect interesting content to > appear. I have a similar routine, but does so all within my email application, which I find much more effective for the task. I'm happy you found what works for you. It just doesn't match my preferences, but that is OK and increases cultural richness. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] [sqlite] Mailing list shutting down...
> Le 14 juin 2018 à 22:30, Thomas a écrit : > > Web forums are much more superior than mailing lists, in any possible > direction. > There's nothing a mailing list can provide a forum can't, since it doesn't > exclude email notifications. > However, there's loads of benefits a forum provides a mailing list can't > catch up with. > That's the reason why mailing lists are disappearing. I respectfully don't agree. Web forums truly have the advantage of being an archive of previous conversations, making it easy for new subscribers to browse or search and partially read previous content at first. There are a number of third-parties aggregators that do the same for mailing-lists, but indeed such an archive run by the mailing-list owners themselves is probably superior if it can at the same time be used by web forums lovers to read and participate in the conversation group. There is nothing right in trying to persuade people that one's idea is everybody's wish and best for them all. People of a certain age know that History, as well as on a much less tragic way, computer industry, has too many examples. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] [sqlite] Mailing list shutting down...
> Le 14 juin 2018 à 22:23, Thomas a écrit : > >> Mailing list messages are easily filtered. >> I have one mailbox for each mailing list I subscribe to, and I read through >> the messages in list order, which makes it easy to mentally switch gears >> from one project to the next. > > Most people only have one mailbox. I presume you're referring to folders. > > >> If one project gets out of hand for a while, I can mark only that one >> mailbox as “read” without declaring email bankruptcy on all my other email. > > Forum software offers the very same functionality but that's not the direct > purpose of it. In a mailing list you're either "in" or "out". A forum > provides all possible options. I routinely follow and participate in about 18 mailing-lists. They're all conveniently aggregated in folders, which is done automatically by rules applied by my IMAP mail server upon arrival.That's comfortable and I have all of it through a single user interface: my email reader. I can easily full-text search on a folder, some or all of them. With a decent email reader and a mailbox managed by a decent, standard compliant, IMAP server, these actions are effective (server-side filtering for instance). I can also set expiration rules to automatically purge older messages, depending on the folder. I can't even imagine myself finding the time and will to visit about 12 to 15 different URLs, user interfaces, to browse and read what might interest me. And then face as much different interfaces to reply conveniently. The right solution to please every wishes is to have a perfectly integrated dual-interface system where the mailing-list and the webforum is *one*. Displaying, encouraging proper threading on the webforum, respectfully matching the email threading. And reciprocal. Such that it wouldn't make any difference if I post per email, reply/quote per email or through the webforum. I'd be free to ignore the existence of the webforum as much as you could ignore it is a mailing list at the same time. Each subscriber electing to have the content delivery additionally per email, or not. Any webforum solution with an email notification mechanism in the style "hey someone just posted a reply" or "there have been 122 posts since your last visit" is useless to me. This is worse than not getting email at all: it pollutes the mailbox with contentless and countless reminders, yet doesn't solve the time-consuming issue to having to pull information from one webforum at a time, using all their different user interfaces. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Fossil with IPv6 support on Windows XP
> Le 5 janv. 2018 à 18:03, Florian Balmer <florian.bal...@gmail.com> a écrit : > >> You might then enjoy a fresh build out of trunk. > > Goes off like a rocket, thanks for the nice work! > > Also, using `GetStdHandle(STD_INPUT_HANDLE)!=NULL' to test whether or > not running in a console session is clever, my proposed solution was > to check for the `ui' and `server' commands. Glad you like it. -You- quickly identified the culprit (StartServiceCtrlDispatcherW out of the context of a Service run), which at least on XP has a lengthly side-effect. :) -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Fossil with IPv6 support on Windows XP
> Le 5 janv. 2018 à 16:47, Florian Balmer <florian.bal...@gmail.com> a écrit : > > Given the portability of Fossil, I was happy it > worked on Windows XP, but waiting 15 seconds for `fossil ui' cools > down my joy a little bit ;-) You might then enjoy a fresh build out of trunk. :) -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Fossil with IPv6 support on Windows XP
> Le 5 janv. 2018 à 15:43, Thomas Schnurrenberger <t...@gmx.net> a écrit : > > On 03.01.2018 23:33, Florian Balmer wrote: >> The startup delay for `fossil ui' and `fossil server' on Windows XP is >> more obvious than possibly sluggish browser navigation, which I >> *think* is due to waiting for StartServiceCtrlDispatcherW. This could >> be cut down by skipping the call to StartServiceCtrlDispatcherW for >> the `ui' and `server' commands, as Fossil always runs in a console >> session, and not as a service, in these cases. >> > I measured the time it takes to call StartServiceCtrlDispatcherW on my > 8 year old Windows 7 64bit box: roughly 600 microseconds, I don't think > this is noticeable! But on XP the delay is 'intolerable' rather than unnoticeable. :) A small patch for that is included along a larger IPv4/IPv6 patch I submitted today. I see Richard put it on trunk (see [e506ebb764]) minutes ago. Especially those of you using Windows XP would help by building from that code and see how it goes for them. It looks good, and does not require anymore to install IPv6 support (command 'ipv6 install') on Windows XP. The solution is IPv4/IPv6 agnostic. If at least one of both protocols are useable, the software should work nicely. As I'm responsible for asking for this support and did a fair part of that coding, I'll stay alert on issues that would come out, in order to quickly help, should it happen. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] zStopperFile / main.c / win32_http_server
Dear,
There is a mechanism related to win32_http_server() based on an optional
filename (find_option("stopper", 0, 1)) which starts a thread, checking every
second the presence of that file and if found triggers the stop of the http
server feature.
I don't get the point of this. It isn't needed nor used when running as a
service (NULL passed for this parameter), only available when running as
command-line (server or ui), and it looks like by default that option is
undefined. Yet I have not seen any issue stopping the process using ctrl-c.
Why would sometimes a file used a semaphore be needed to trigger the
termination of the http serving feature?
There must be something I didn't understand or see. Or this is a left-over
from something else. Would someone have an insider view on the matter?
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
___
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] Fossil with IPv6 support on Windows XP
t back to normal for Windows XP users, provided they agree to run once and for all "ipv6 install" to add IPv6 protocol support to their system. Open for discussion, of course, but please first test with [723dedac] along the above one line change patch. On my Windows XP test VM which happen to be XP Professional SP3, it works and looks just fine (provided you have installed some other browser than the stock IE of course). Depending on return from people, I will happily spend more time offering our community a more complex / complete solution, that wouldn't impact in any way Windows XP users, including retiring the need to add IPv6 protocol. Though I think that is probably not needed. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] pragma journal_mode=wal
> Le 3 janv. 2018 à 13:03, Olivier Mascia <o...@integral.be> a écrit : > > Is the page size 8K, instead of SQLite current default of 4K which Fossil > preserves on a "fossil new" for instance, also a generally > preferred/recommended configuration for Fossil repositories, or an ad-hoc > setting for this specific repository? Along the same line... I see "fossil new" uses the default SQLite page size of 4K. Though "fossil clone http://www.fossil-scm.org/ fossil.fossil" do reproduce locally the 8K page size from its source. What other technical settings of a cloned repository are implicitly preserved to its clones? (The journal_mode=WAL is not, and I understand why it is so). -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] pragma journal_mode=wal
> Le 3 janv. 2018 à 12:57, Richard Hipp <d...@sqlite.org> a écrit : > > WAL-mode is preferred. Thanks! > If you visit https://www.fossil-scm.org/fossil/stat and look at the > end of the "Database Stats:" line, you'll see that the canonical > Fossil repo runs in WAL mode. Is the page size 8K, instead of SQLite current default of 4K which Fossil preserves on a "fossil new" for instance, also a generally preferred/recommended configuration for Fossil repositories, or an ad-hoc setting for this specific repository? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] pragma journal_mode=wal
Dear, Assuming a main repository only accessed through HTTP for clone, push, pull or through its web interface... Would you see a reason for not switching it to WAL mode? Should it be avoided for a well-known reason in that restricted configuration? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil with IPv6 support on Windows XP
Dear, I could finally re-install a VM with a plain old stock "Windows XP with Service Pack 3", to re-run a series of tests, because I had some fears. Here are some findings for you to consider. Out of fresh install, IPv6 is not setup. So fossil ui and fossil server will both fail listening on a socket. That is expected. Actions where fossil acts as a client (fossil clone/push/pull for instance) will work correctly though. On Windows XP, you have to run the command "ipv6 install" to add the protocol to the stack (much simpler than through the GUI). A reboot is NOT required (as incredible as it looks). After that, again, fossil as a client (fossil clone/push/pull) will work correctly this time either to an IPv4 or IPv6 target. Though, fossil ui will fail with "unable to open listening socket", while fossil server will succeed. The root culprit is here: https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_config_items.mspx?mfr=true in the "Special addresses" paragraph: "The IPv6 protocol for Windows (XP) does not support the use of IPv4-mapped addresses." As implementing a dual-stack listening socket implies IPv4-mapped addresses, this explains the problem. It could be solved by modifying fossil server/ui to listen on two distinct sockets (one pure IPv4 and one pure IPv6). That would also work on all other Windows versions. I think this is not a very useful complication. Anyone still requiring to use fossil on such archeologic thing as Windows XP won't have any specific issue with fossil, except the requirement to run fossil server instead of fossil ui before accessing the content through http://localhost (that will work nicely). It just kills the prospect of setting up a fossil server (on Windows XP only) for generic access from both IPv4 and IPv6 clients. I suppose that is a small limitation people can live with, seeing, if I'm not mistaken, that fossil doesn't yet support IPv6 at all on unixes. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Login bug (and fix) with trunk since added IPv6 support on Windows
I have discovered a bug this morning on Windows using trunk as of [21d5038fd0]:
the login mechanism is broken, because at some point it relies on the IP
address being in the cookie, but the WSAAddressToString() Windows function
which had to be used in winhttp.c for backward compatibility down to XP also
outputs the port number. In addition, facing an IPv6 address, let's say ::1 it
creates a string as [::1]:12345 (12345 being the port in this sample). This
breaks the login mechanism.
Here is an easy fix based on [21d5038fd0], tested with msvc 2017 and MinGW.
It works by zeroing the port number of the remote address before converting to
string. With port set to 0, WSAAddressToString stops appending the port number
to the string.
So ::1 stays ::1 and not [::1]:12345
The login mechanism works again after this.
Index: src/winhttp.c
==
--- src/winhttp.c
+++ src/winhttp.c
@@ -190,10 +190,11 @@
/*
** The repository name is only needed if there was no open checkout. This
** is designed to allow the open checkout for the interactive user to work
** with the local Fossil server started via the "ui" command.
*/
+ p->addr.sin6_port = 0;
if( WSAAddressToStringA((SOCKADDR*)>addr, sizeof(p->addr),
NULL, zIp, )!=0 ){
zIp[0] = 0;
}
if( (p->flags & HTTP_SERVER_HAD_CHECKOUT)==0 ){
@@ -277,10 +278,11 @@
if( got<=0 ) break;
fwrite(zHdr, 1, got, out);
wanted += got;
}
assert( g.zRepositoryName && g.zRepositoryName[0] );
+ p->addr.sin6_port = 0;
if (WSAAddressToStringA((SOCKADDR*)>addr, sizeof(p->addr),
NULL, zIp, )!=0){
zIp[0] = 0;
}
sqlite3_snprintf(sizeof(zCmd), zCmd,
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
___
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] How to cleanup two leafs on private branch?
> Le 2 janv. 2018 à 00:11, Olivier Mascia <o...@integral.be> a écrit : > >> Run "fossil ui". Find the leaf you want to close. Click on the >> "Edit" link. Select "Leaf Closure", followed by "Preview" and >> "Submit". > > I guess I played fool or broke something on this configuration. I have no > Edit link. Other Links only shows: manifest | tags. Login issue. Did not take note of the password automatically set on my default user upon cloning the repository. Learned the lesson :) -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Building fossil on Windows using MinGW
Just sharing my findings, if it is useful to anyone. I was looking for an easy way to sort my path setting up some version of MinGW to build fossil trunk (for 32 bits) on Windows. I needed it to get a 32 bits build suitable for tests on Windows XP. The build environment is Server 2016, which for this purpose is Windows 10 alike. I could not use my Visual Studio 2017, because that requires installing an optionally toolset pack (which I can't for obscure internal policies reasons). That optional toolset specifically targets Windows XP compatibility (the default up-to-date toolset of Visual Studio 2017 produces executables that cannot run on Windows XP). There are MinGW and MinGW-w64 which are two distinct projects. Apparently the first one is older and limited to 32 bits (I may be wrong on this). The other one is much more up to date, targeting both 32 and 64 bits but I haven't found a way to complete my setup satisfactorily. So using http://www.mingw.org, I knew I would end up with an older setup but suited to the task. ## My steps to setup MinGW. Follow the Downloads link from the top bar, leading you to https://sourceforge.net/projects/mingw/files/ From the Installer folder, download and run mingw-get-setup.exe Following the steps of the installer (I only opted out from links on the desktop), you end up with a GUI to manage your packages. From the Basic Setup node I only selected 'mingw-developer-toolkit', 'mingw32-base' and 'msys-base'. Then hit Apply. A few minutes later, it is done. ## My steps to set myself ready to compile fossil. Start a windows command prompt. Run C:\MinGW\msys\1.0\msys.bat to open up another prompt with a sh prompt. Ended up in my home directory which happen to read '/home/Olivier' (pwd) and that actually is C:\MinGW\msys\1.0\home\Olivier. ## Building fossil Assuming some fossil.exe is already in your windows path (which is easy to fix downloading a pre-built binary), I did nothing more than what I expected: $ mkdir fossil $ cd fossil $ fossil clone http://www.fossil-scm.org/ fossil.fossil $ fossil open fossil.fossil $ make win/Makefile.mingw And voilà: $ fossil version -v This is fossil version 2.5 [21d5038fd0] 2018-01-01 18:56:19 UTC Compiled on Jan 2 2018 00:02:38 using mingw32-501L-gcc-6.3.0 (32-bit) -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] How to cleanup two leafs on private branch?
> Le 1 janv. 2018 à 23:55, Richard Hipp <d...@sqlite.org> a écrit : > > On 1/1/18, Olivier Mascia <o...@integral.be> wrote: >> I just would like to 'close' those leafs > > Run "fossil ui". Find the leaf you want to close. Click on the > "Edit" link. Select "Leaf Closure", followed by "Preview" and > "Submit". I guess I played fool or broke something on this configuration. I have no Edit link. Other Links only shows: manifest | tags. I'll trash it all (that was only clone of http://www.fossil-scm.org/) and restart testing with more attention to details. Thanks! -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] How to cleanup two leafs on private branch?
Dear, Still learning Fossil. Ended up after various experiments with two leafs on my private branch. Something like: WARNING: multiple open leaf check-ins on private: (1) 2018-01-01 17:21:25 [cf17bd1315] (current) (2) 2017-12-31 12:49:25 [6e96981da8] There is really nothing wrong. I just would like to 'close' those leafs or the whole private branch and re-use it later for other purposes. I'm learning so will probably find my way within 'some time'. Would you have a hint for me? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] _WIN32 IPv6/IPv4 fossil server / ui support
> Le 1 janv. 2018 à 01:20, The Tick <the.t...@gmx.com> a écrit : > >> Could you lend me pointers on which MinGW version to get (and from where) so >> I can have a similar setup as yours? >> I didn't used MinGW these last years (though did in the past). >> Just visited www.mingw.org, but it looks like the pointers to download there >> are severely outdated (2013?). >> Is this the right current MinGW project? >> > Don't know if this would be helpful but I've been using MSYS2 -- that project > is kept up-to-date with their pacman tool and they have both a 32- and 64-bit > gcc. There is also a mingw flavored gcc but I am not sure how it differs from > the msys2 flavored gcc. Thanks. Got msys2 configured for now. I guess what I'll need is simply the recipe from Fossil developers on what 'MingGW' setup they use and how they trigger the build using those tools, so I can reproduce building Fossil correctly with that configuration and give a hand to complete the win-server-ipv6 branch, using those tools. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] _WIN32 IPv6/IPv4 fossil server / ui support
> Le 31 déc. 2017 à 21:03, Richard Hipp <d...@sqlite.org> a écrit : > > Your changes (with some minor alterations by me) are now on a branch. Good. Found it. Thanks for the C89 fix. > They do not build using MinGW, sadly. I don't know how to fix it. > Maybe somebody else on the mailing list can accomplish that? Surely. [I'm posting this to the list.] Could you lend me pointers on which MinGW version to get (and from where) so I can have a similar setup as yours? I didn't used MinGW these last years (though did in the past). Just visited www.mingw.org, but it looks like the pointers to download there are severely outdated (2013?). Is this the right current MinGW project? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Replacing subversion revision number... by what?
Le 29 déc. 2017 à 17:04, Mark Janssen <mpc.jans...@gmail.com> a écrit : > > And how will you handle diverging repos so that my version 12 is not > your version 12, because I didn't sync after commit 10? Irrelevant, to me. As said, no public released code will get out of anywhere except from a dedicated repo (let’s call it the root one) from which development repo are cloned from. We’re not in an open-source scenario where anybody would build a public-distributed binary out of his own local repo. Anyone with code access (right to clone repo) can build a release build (for testing purposes for instance), but such a build would not be publicly distributed, if only because it couldn’t be EV code signed (no access to private keys to do so). Well in between of these exchanges I could complete the overhaul of our production build automaton and this technique fits the bill nicely. So thank you all for your valuable inputs on the matter. They not always applied to the specific concern, but were very interesting in all cases. Season’s greetings to all of you, -- Best regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia (from mobile device), http://integral.software ___ 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] fossil server on a small private LAN
Le 29 déc. 2017 à 12:31, Richard Hipp <d...@sqlite.org> a écrit : >> In my own code, I generally end up including: >> >> #include >> #include >> #include >> >> in code units using MS winsock. >> >> I'll soon see what would fit for fossil win32 networking. > > Please keep in mind that Fossil current compiles using both MSVC and > MinGW. We'd like to continue supporting both build environments. > Thanks for your help! Understood. I’ll keep that in mind. Good opportunity for me to refresh a MinGW setup on my computer! -- Best regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia (from mobile device) ___ 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] fossil server on a small private LAN
> Le 29 déc. 2017 à 01:17, Richard Hipp <d...@sqlite.org> a écrit : > > On 12/28/17, Olivier Mascia <o...@integral.be> wrote: >> To get a proper dual-stack socket, the socket must be created with AF_INET6 >> first then setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,...) > > When I try to do this I get: error C2065: 'IPV6_V6ONLY': undeclared > identifier > > MSVC 2015 In my own code, I generally end up including: #include #include #include in code units using MS winsock. I'll soon see what would fit for fossil win32 networking. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] fossil server on a small private LAN
> Le 29 déc. 2017 à 02:30, Richard Hipp <d...@sqlite.org> a écrit : > > On 12/28/17, Thomas <tho...@dateiliste.com> wrote: >> >> This could be an option too: >> #ifndef IPV6_V6ONLY >> #define IPV6_V6ONLY 27 >> #endif > > It compiles with that. But it doesn't work. So for now, I think > we'll just stick with IPv4-only servers for "fossil server" on windows > - at least until somebody can suggest a way to fix it. I'll happily take on that task, but it will probably be after Jan 2. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Replacing subversion revision number... by what?
> Le 28 déc. 2017 à 23:58, Joerg Sonnenberger <jo...@bec.de> a écrit : > >>>> I'm considering replacing the subversion revision ID, for the purpose of >>>> defining the file version ID (as above) at release-external build time, by >>>> the count of check-ins in the root repository. That is the count returned >>>> by 'fossil info' in one of the multiple lines of output (for instance >>>> 'check-ins: 8801'). >> >> My 'count of check-ins' is your 'length of the commit chain to the root', or >> are we talking of something else here? > > If you have a commit graph like: > > A > | > B > | \ > C D > | | > E F > > Both E and F have a LoCC of 4, but the count f check-ins would depend on > the order of commits? That I don't know yet for sure. I just want an integer, always increasing, even though not by one, from a specific branch, from a specific repository (the branch/repository from which I compile released code). And that value seems to fit that need perfectly. It does not need to allow me backward lookups (finding a check-in from that number). That sequential number could even be managed outside by my build system. But it is interesting that it be linked with the count of check-ins, because somehow it gives an empiric sense "of the distance" of code between to release builds. Which we had before through the subversion revision ID. Upon build I will derive the trailing version number of my executables from that integer. And my build system will auto add a tag with the full constructed version number to the top check-in of that same branch. I can also store that top check-in ID (hash) somewhere else (than in the version number) so it could be displayed on request. And there, thanks to the auto-added full version number tag upon successful release build, I get an easy way to locate the exact source code that was part of that build. It's easier for users to tell support people their version number than a hash code, even shortened. And setup/distribution is easier thanks to an ever increasing full version number, even between patch builds of a same release. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] fossil server on a small private LAN
> Le 28 déc. 2017 à 17:37, Olivier Mascia <o...@integral.be> a écrit :
>
> The quick/easy/dirty/temporary fix before completing the proper support
> (server-side) of IPv4+IPv6 would be to simply adjust the hint.ai_family
> initialisation in http_socket.c::socket_open to read:
>
> #ifdef _WIN32
> hints.ai_family = AF_INET;
> #else
> hints.ai_family = g.fIPv4 ? AF_INET : AF_UNSPEC;
> #endif
>
> It works nicely for me. Perfectly expected performance of a large clone
> (needing 250 round-trips) in about 50 seconds. Either using explicitly IPv4
> in the URL or, with that patch, the proper DNS name.
To further clarify, here is the patching I did today based on fossil version
2.5 [f4a9df4dd0] 2017-12-23 04:21:41 UTC.
There is that discussed temporary limitation of the client-side (on Windows) to
resolving only to IPv4 (to match the server being only IPv4) and another small
change which is to call shutdown() on sockets before calling closesocket().
It is more interesting in winhttp.c than in http_socket.c, because it will help
the windows TCP stack to more cleanly and generally more quickly free up kernel
resources by sending the proper TCP FIN before getting rid of the socket. Kind
of warning "I'm pulling the plug" before actually doing so.
Don't expect measurable performance improvement from that. The only benefit
would be seen under rare situations when the server machine has thousands of
other sockets active (maybe other softwares than Fossil). And even so, would be
seen only if those other software also behave 'by the book'.
Index: src/http_socket.c
==
--- src/http_socket.c
+++ src/http_socket.c
@@ -119,10 +119,12 @@
** is a no-op.
*/
void socket_close(void){
if( iSocket>=0 ){
#if defined(_WIN32)
+if (shutdown(iSocket, 1/*SD_SEND*/) == 0) /* Initiates the shutdown,
sending TCP 'FIN' */
+ shutdown(iSocket, 0/*SD_RECEIVE*/); /* Now denies receive */
closesocket(iSocket);
#else
close(iSocket);
#endif
iSocket = -1;
@@ -147,11 +149,15 @@
char zRemote[NI_MAXHOST];
socket_global_init();
socket_close();
memset(, 0, sizeof(struct addrinfo));
+#ifdef _WIN32
+ hints.ai_family = AF_INET;
+#else
hints.ai_family = g.fIPv4 ? AF_INET : AF_UNSPEC;
+#endif
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
sqlite3_snprintf(sizeof(zPort),zPort,"%d", pUrlData->port);
rc = getaddrinfo(pUrlData->name, zPort, , );
if( rc ){
Index: src/winhttp.c
==
--- src/winhttp.c
+++ src/winhttp.c
@@ -214,10 +214,12 @@
}
end_request:
if( out ) fclose(out);
if( in ) fclose(in);
+ if (shutdown(p->s, 1/*SD_SEND*/) == 0) /* Initiates the shutdown, sending
TCP 'FIN' */
+shutdown(p->s, 0/*SD_RECEIVE*/); /* Now denies receive */
closesocket(p->s);
file_delete(zRequestFName);
file_delete(zReplyFName);
file_delete(zCmdFName);
fossil_free(p);
@@ -277,10 +279,12 @@
}
end_request:
if( out ) fclose(out);
if( in ) fclose(in);
+ if (shutdown(p->s, 1/*SD_SEND*/) == 0) /* Initiates the shutdown, sending
TCP 'FIN' */
+shutdown(p->s, 0/*SD_RECEIVE*/); /* Now denies receive */
closesocket(p->s);
file_delete(zRequestFName);
file_delete(zReplyFName);
fossil_free(p);
}
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
___
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] fossil server on a small private LAN
> Le 28 déc. 2017 à 17:18, Richard Hipp <d...@sqlite.org> a écrit : > > There is one thread per connection in the parent process, which allows > the parent to manage multiple simultaneous incoming connections. As > each thread gets a complete HTTP request, it writes that request into > a temporary file, uses fossil_system() to invoke the "fossil http" > command to handle the request and store the reply into a second > temporary file, then the thread reads the reply and sends it back over > the wire. Finally, the two temporary files are deleted. > > The fork() approach is much nicer, but we don't have fork() on > windows. I'm open to suggests on better ways to do this. Unless your intend is to be able to support thousands of simultaneous requests, there is few to earn in changing this scheme. The scaling limitation would be that spawning of sub-processes. Overcoming that is possible, but is a major redesign of the very clear and simple winhttp.c you currently have. I wouldn't loose precious time in that area. As pointed in my other message, the main culprit of occasional sluggish windows behaviour when fossil reaches out a windows fossil server is that the server inadvertently implements an IPv4-only listening socket while the client is dual-stacked. It can loose seconds (in the order of multiple times 10 or 20 seconds) per IPv6 connection attempt not answered by the remote server before finally trying an IPv4 address and succeeding its connection. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] fossil server on a small private LAN
> Le 28 déc. 2017 à 16:55, Olivier Mascia <o...@integral.be> a écrit :
>
>> I'll experiment with the fossil code here. Familiarizing with winhttp.c for
>> now.
>
> I haven't yet come to bottom of it, but using IP (IPv4) in the URL (instead
> of name) changes it all!! There seem to be a high price paid in resolving
> the server name on each round trip (from client). This or, due to dual-stack
> being the norm on Windows, client connections loose time trying IPv6
> (generally preferred by Windows when DNS reports both and A records for
> a name) before falling back to IPv4.
>
> My test now runs (the network portion, excluding rebuilding metadata and next
> things) within 50 seconds for all 250 round-trips and 102700 artifacts
> received. It was close to 1 hour and a half before.
>
> I'm further analysing http_socket.c (socket_open) following this discovery.
Okay, it revolves around g.fIPv4 which only appears in these lines:
Search "fIPv4" (3 hits in 3 files)
I:\fossil\src\http_socket.c (1 hit)
Line 154: hints.ai_family = g.fIPv4 ? AF_INET : AF_UNSPEC;
I:\fossil\src\main.c (1 hit)
Line 159: int fIPv4; /* Use only IPv4, not IPv6. --ipv4
*/
I:\fossil\src\url.c (1 hit)
Line 382: if( find_option("ipv4",0,0) ) g.fIPv4 = 1;
In http_socket.c it is tested to configure hints.ai_family with either AF_INET
or AF_UNSPEC in order to query for only IPv4 or both IPv6 and IPv4. The server
name resolution made by the client then returns both IPv6 and IPv4 because I
didn't mentioned "--ipv4" option anywhere in my commands. Further, enumerating
the IPs, the code attempts socket creation *and* connection, trying the next
returned IP if the connect fails.
Sounds good isn't it?
No. Because the server side never ever initialised a listening socket for
dual-stack. It listens on IPv4 only. Leading to long pauses from the client
trying IPv6 connections, unresponding, before trying next one which might
happen to be IPv4 and reachable.
The server code do initialize its listening socket as this:
s = socket(AF_INET, SOCK_STREAM, 0);
That (on Windows) gives you an IPv4-limited socket.
To get a proper dual-stack socket, the socket must be created with AF_INET6
first then setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,...) should be called to
remove the "only IPv6" attribute from the socket. See
https://msdn.microsoft.com/en-us/library/windows/desktop/ms738574(v=vs.85).aspx.
That is not the only thing to do because the test that follows on the validity
of the IP address would have to be adjusted to take IPv4/IPv6 into account.
So the current situation is simply that when acting as server, fossil.exe setup
an IPv4-only listening socket, while by default it will attempt dual-stack
client connections, loosing a huge amount of time re-establishing those
connections. Add to this that recent Windows will reorder the IPs returned by
getaddrinfo() as to list IPv6 first when the OS looks like having proper IPv6
internet connectivity.
The quick/easy/dirty/temporary fix before completing the proper support
(server-side) of IPv4+IPv6 would be to simply adjust the hint.ai_family
initialisation in http_socket.c::socket_open to read:
#ifdef _WIN32
hints.ai_family = AF_INET;
#else
hints.ai_family = g.fIPv4 ? AF_INET : AF_UNSPEC;
#endif
It works nicely for me. Perfectly expected performance of a large clone
(needing 250 round-trips) in about 50 seconds. Either using explicitly IPv4 in
the URL or, with that patch, the proper DNS name.
I'll see to help with proper Windows dual-stack server socket in January.
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
___
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] fossil server on a small private LAN
> Le 28 déc. 2017 à 15:42, Olivier Mascia <o...@integral.be> a écrit : > > I'll experiment with the fossil code here. Familiarizing with winhttp.c for > now. I haven't yet come to bottom of it, but using IP (IPv4) in the URL (instead of name) changes it all!! There seem to be a high price paid in resolving the server name on each round trip (from client). This or, due to dual-stack being the norm on Windows, client connections loose time trying IPv6 (generally preferred by Windows when DNS reports both and A records for a name) before falling back to IPv4. My test now runs (the network portion, excluding rebuilding metadata and next things) within 50 seconds for all 250 round-trips and 102700 artifacts received. It was close to 1 hour and a half before. I'm further analysing http_socket.c (socket_open) following this discovery. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] fossil server on a small private LAN
> Le 28 déc. 2017 à 15:04, Richard Hipp <d...@sqlite.org> a écrit : > > On 12/28/17, Richard Hipp <d...@sqlite.org> wrote: >> >> Running multiple copies of the new fossil-stress.tcl script >> (https://www.fossil-scm.org/fossil/file/tools/fossil-stress.tcl) from >> a linux box against a windows laptop confirms that the "fossil server" >> command on Windows sometimes latches up. > > Preliminary findings are that this latch-up is the result of an > adverse interaction with built-in anti-virus software on Win10. You > *might* have more success by disabling anti-virus on your server - if > you dare. We'll try to figure out a way to fix the problem in fossil, > in the meantime. Confirmed that server on macOS, client on Windows (server 2016 and server 2012 R2) is OK. Server and client on same Windows box, through localhost is comparable (just slightly slower) to server macOS and client Windows. I'll dig in the source code over the week-end. Generally, there are subtle TCP window issues to take into account when configuring sockets on various Windows versions, along side with setting up the 'just-right' buffer sizes on those sockets to get it right and not have traffic stalling unexpectedly. Been there in our own projects. I'll experiment with the fossil code here. Familiarizing with winhttp.c for now. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] fossil server on a small private LAN
> Le 28 déc. 2017 à 13:51, Richard Hipp <d...@sqlite.org> a écrit : > > On 12/28/17, Olivier Mascia <o...@integral.be> wrote: >> >> Is "fossil server" generally deemed sufficient for a small LAN (lab) of >> let's say < 10 developers each with their own clone ? >> Or should a proper HTTP server be used as front end to SCGI mode of fossil? > > The "fossil server" command *should* be sufficient for this. However, > it doesn't get used that much. Most people run from a proper HTTP > server of some kind. Consequently, it is possible for bugs to linger > in "fossil server" without anybody noticing. One such performance > bug, that had been in the code for over 10 years, was fixed just > before Chrismas > (https://www.fossil-scm.org/fossil/info/05ec15cad53e8176). That > particular fix applies to unix systems only, but there might be > similar problems on the windows side. > > As a test of last weeks' fix, I am currently running a clone of the > Fossil self-hosting repository using the "fossil server" command in a > datacenter near Paris on a machine that is approximately equal to a > Raspberry Pi. The clone is internet-facing > (http://www4.fossil-scm.org/) and so far seems to be holding up fine. > > I just took a peek at the code for "fossil server" on windows. > (Unlike most other commands in fossil, the "fossil server" command > requires a separate implementation in windows.) I am reminded that > windows is not the ideal platform on which to host a web server and > that compromises had to be made in the implementation. It *should* > work. And it does work fine for things like "fossil ui". But if you > start hitting it with any kind of load, I can see that it might easily > bog down. Probably it will take someone with more windows-foo than me > to fix that. > > So if you are having problems using "fossil server" on Windows, you > might do well to set up a Raspberry PI (or the equivalent) in the > corner of the room and run "fossil server" there instead, using the > latest "trunk" version of Fossil that contains the Christmas-eve patch > for the "fossil server" inefficiency. Thanks a lot Richard for this insider view on the matter. I'll not get down to Raspberry PI (which I really like by the way) but spawn a common linux VM for the task and I'm confident, reading your comments, that it will be just fine. By the way, in between, the clone completed successfully. Here is the display at end (project ids and password removed). Round-trips: 250 Artifacts sent: 0 received: 102700 *** time skew *** server is slow by 106.6 seconds Clone done, sent: 85932 received: 2249557802 ip: 10.32.1.6 Rebuilding repository meta-data... 100.0% complete... Extra delta compression... Vacuuming the database... I'll have a close look in the next weeks at the source code of the Windows server feature of Fossil. The warning "*** time skew *** will certainly be an interesting starting point. Hopefully I might be able to bring something in that area. Our own software is actually much like Fossil: single process, multi-usages, with its own HTTPS embedded server (using OpenSSL). (Albeit currently only available on Windows, so we have good experience in that area of HTTP serving on Windows using custom C/C++ code). For information, my strange experience today was running this code (on both server and cloner side): This is fossil version 2.5 [f4a9df4dd0] 2017-12-23 04:21:41 UTC Compiled on Dec 27 2017 16:08:53 using msc-19.11 (64-bit) -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] fossil server on a small private LAN
> Le 28 déc. 2017 à 12:26, Olivier Mascia <o...@integral.be> a écrit : > > Dear, > > Is "fossil server" generally deemed sufficient for a small LAN (lab) of let's > say < 10 developers each with their own clone ? > Or should a proper HTTP server be used as front end to SCGI mode of fossil? > > From some quick-n-dirty tests (yeah, on a Windows server, not the best of all > ideas but simply convenient right now), it looks like cloning a 2 GB > repository through http over 1 Gbps LAN is curiously slow and I wonder why. > Not that we'll clone every day of course, but it looks so slow that it > questions stability. To give context to this situation, I'm now 45 minutes later and it still is not complete. fossil clone http://olivier@something:8081/repotest repotest-om.fossil password for olivier: * remember password (Y/n)? Y Round-trips: 138 Artifacts sent: 0 received: 82563 ... The computer running fossil server is doing "nothing", 1 or 2% cpu consumed, LAN mostly calm. The computer pulling the clone does the same. I'm not seeing significant disk IO on any of them. The LAN segment they're both on has a background noise of about 1 Mbps with short peaks of less than 50 Mbps while this is ongoing. It really looks as if either the fossil process running the clone OR the fossil process running the server is abnormally slow doing its work. I'll probably retry such a clone locally (over http but both processes on same machine, through localhost) to try to get an understanding of what's going on. I must admit it awfully looks like a pure networking issue, but I tested a file transfer minutes before rerunning this clone test and I peaked 940 Mbps on the wire easily. A Gremlin, there is. Who's got some water? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil server on a small private LAN
Dear, Is "fossil server" generally deemed sufficient for a small LAN (lab) of let's say < 10 developers each with their own clone ? Or should a proper HTTP server be used as front end to SCGI mode of fossil? From some quick-n-dirty tests (yeah, on a Windows server, not the best of all ideas but simply convenient right now), it looks like cloning a 2 GB repository through http over 1 Gbps LAN is curiously slow and I wonder why. Not that we'll clone every day of course, but it looks so slow that it questions stability. I'll spawn a linux VM or re-test from a Mac machine to get new experiences, but maybe there are anyway things to pay attention to, which I didn't (yet). -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Replacing subversion revision number... by what?
> Le 28 déc. 2017 à 00:07, bch <brad.har...@gmail.com> a écrit : > > The chain-length method Joerg mentioned is roughly what I was thinking, > bounded to a single branch “namespace” to manage disambiguation. Mind, this > is off the top of my head, not a thing I’ve implemented. Thanks Brad. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Replacing subversion revision number... by what?
> Le 27 déc. 2017 à 23:10, bch <brad.har...@gmail.com> a écrit : > > On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia <o...@integral.be> wrote: > Hello, > > Coming from subversion where there is a revision number, incremented by one > by each commit, > > > Let me be the first of many to say that those centrally controlled increments > are not possible in a *distributed* source control system. Maybe a “feature > branch” and your own heuristics would fit the bill? Brad, I think I know that and wrote it in my message. The question was indeed about my proposed heuristic to use the count of check-ins: > Of course this characteristic (a sequential revision ID) is logical in a > centrally managed system as subversion and is less trivial in distributed scm > like fossil or git. > > I'm considering replacing the subversion revision ID, for the purpose of > defining the file version ID (as above) at release-external build time, by > the count of check-ins in the root repository. That is the count returned by > 'fossil info' in one of the multiple lines of output (for instance > 'check-ins: 8801'). > > The full version string (as "1.2.4.8801") would then be automatically added > as a tag to the most recent check-in on trunk (from which the build is > derived). > > How does that sound to those of you who might have had similar concerns? > Been there and rushed away? Or happy to stay? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Replacing subversion revision number... by what?
Hello, Coming from subversion where there is a revision number, incremented by one by each commit, which is very easy to capture in automated builds to be injected as part of the version number of binaries built... Revision 8745 -> version x.y.z.8745 Revision 8789 -> version x.y.z.8789 The x.y.z is incremented by hand when it means something (release of some tested version). But for the lifetime of a version, there might be some newer builds (small fixes) and they will be auto-tagged with the revision ID as last part of the full version number. In real life this can lead to sequences of file version numbers as: 1.2.3.8745 1.2.3.8749 1.2.4.8801 ... This has many advantages, not the least being to easily spot which among two binaries is more up to date (has simplifications in setup systems). The main limitation is that (on Windows) those 4 parts of a full file version id are each limited to 16 bits. Limiting this model to about 65.000 revisions. After which some offset should be applied (which is easy to do every time the first 3 values are hand changed). Of course this characteristic (a sequential revision ID) is logical in a centrally managed system as subversion and is less trivial in distributed scm like fossil or git. I'm considering replacing the subversion revision ID, for the purpose of defining the file version ID (as above) at release-external build time, by the count of check-ins in the root repository. That is the count returned by 'fossil info' in one of the multiple lines of output (for instance 'check-ins: 8801'). The full version string (as "1.2.4.8801") would then be automatically added as a tag to the most recent check-in on trunk (from which the build is derived). How does that sound to those of you who might have had similar concerns? Been there and rushed away? Or happy to stay? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] question regarding fuel-scm maintenance / ownership
> Le 27 déc. 2017 à 17:25, Chris Drexler <ckolum...@ac-drexler.de> a écrit : > >> If you are unable to make contact, you might consider "forking" the project >> (under a new name) and maintaining it yourself. > > The project is currently available at > > https://server.ac-drexler.de/fossil/fuel > > if anyone is interested. What Fossil version(s) does Fuel works with? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Where would fossil.exe write some log when running as a service?
> Le 27 déc. 2017 à 14:49, Olivier Mascia <o...@integral.be> a écrit : > > On one computer (running Server 2016), I have: > > fossil version -v > This is fossil version 2.5 [f4a9df4dd0] 2017-12-23 04:21:41 UTC > Compiled on Dec 27 2017 13:45:17 using msc-19.11 (64-bit) > > And I can run it as a service. > ... > On another computer (which is 2012 R2), the exact same binary fails to run as > a service. > ... > It is not started because upon attempt to start it, it fails and stops. > Attempting to start it by "fossil winery start fossil" displays dots > endlessly. But I have no clue as to what this happens without any kind of > log of what might go wrong. The Event Viewer simply confirms it started and > then failed to start (or stop). > > Running "C:\Develop\Fossil\fossil.exe" server --repolist "C:/Develop/Fossil" > from a command-line is OK though. Fun. Fixed. Added -P 8081 to the fossil winsrv create command line. It didn't occurred to me immediately, but when ran from command-line the web service exposed itself from port 8081 and not 8080. So I suspected that maybe in service mode it might not auto-correct the port (8080 is indeed occupied by another software on *that* machine). Bingo. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Where would fossil.exe write some log when running as a service?
> Le 27 déc. 2017 à 15:52, Olivier Mascia <o...@integral.be> a écrit :
>
>> Le 27 déc. 2017 à 14:49, Olivier Mascia <o...@integral.be> a écrit :
>>
>> On one computer (running Server 2016), I have:
>>
>> fossil version -v
>> This is fossil version 2.5 [f4a9df4dd0] 2017-12-23 04:21:41 UTC
>> Compiled on Dec 27 2017 13:45:17 using msc-19.11 (64-bit)
>>
>> And I can run it as a service.
>> ...
>> On another computer (which is 2012 R2), the exact same binary fails to run
>> as a service.
>> ...
>> It is not started because upon attempt to start it, it fails and stops.
>> Attempting to start it by "fossil winery start fossil" displays dots
>> endlessly. But I have no clue as to what this happens without any kind of
>> log of what might go wrong. The Event Viewer simply confirms it started and
>> then failed to start (or stop).
>>
>> Running "C:\Develop\Fossil\fossil.exe" server --repolist "C:/Develop/Fossil"
>> from a command-line is OK though.
>>
>> Indeed the configuration is not rigorously the same between both machines,
>> the paths where fossil.exe is located (along with the repository) are
>> different. But that doesn't look suspect.
>>
>> So what would you suggest I look for?
>
> Just built a new binary out of branch-2.4, I see the exact same behaviour. OK
> on one server, fails to start on another. So it probably is related to some
> environmental / configuration detail differing between these two computers.
> But I'm still rather clueless to find what triggers the failure without any
> kind of logging or specific error code from the service startup. Works fine
> from command-line, fails to start when configured as service. Oh yes, I could
> make a debug build and attempt to start it as a service under debugger, but
> that is generally tricky to do, unless you can attach to the service
> executable *after* it started. Here it fails to start...
So as to give context to what I mean by not having clues to what's happening,
here is the exit code returned by the Windows service controller (1067, "The
process terminated unexpectedly"). It just means though it begins, it then
properly exits (unexpectedly for the service controller) or more probably
simply crash.
C:\Develop\Fossil>sc query fossil
SERVICE_NAME: fossil
TYPE : 10 WIN32_OWN_PROCESS
STATE : 1 STOPPED
WIN32_EXIT_CODE: 1067 (0x42b)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
C:\Develop\Fossil>net helpmsg 1067
The process terminated unexpectedly.
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
___
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] Where would fossil.exe write some log when running as a service?
> Le 27 déc. 2017 à 14:49, Olivier Mascia <o...@integral.be> a écrit : > > On one computer (running Server 2016), I have: > > fossil version -v > This is fossil version 2.5 [f4a9df4dd0] 2017-12-23 04:21:41 UTC > Compiled on Dec 27 2017 13:45:17 using msc-19.11 (64-bit) > > And I can run it as a service. > ... > On another computer (which is 2012 R2), the exact same binary fails to run as > a service. > ... > It is not started because upon attempt to start it, it fails and stops. > Attempting to start it by "fossil winery start fossil" displays dots > endlessly. But I have no clue as to what this happens without any kind of > log of what might go wrong. The Event Viewer simply confirms it started and > then failed to start (or stop). > > Running "C:\Develop\Fossil\fossil.exe" server --repolist "C:/Develop/Fossil" > from a command-line is OK though. > > Indeed the configuration is not rigorously the same between both machines, > the paths where fossil.exe is located (along with the repository) are > different. But that doesn't look suspect. > > So what would you suggest I look for? Just built a new binary out of branch-2.4, I see the exact same behaviour. OK on one server, fails to start on another. So it probably is related to some environmental / configuration detail differing between these two computers. But I'm still rather clueless to find what triggers the failure without any kind of logging or specific error code from the service startup. Works fine from command-line, fails to start when configured as service. Oh yes, I could make a debug build and attempt to start it as a service under debugger, but that is generally tricky to do, unless you can attach to the service executable *after* it started. Here it fails to start... -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Where would fossil.exe write some log when running as a service?
Dear, On one computer (running Server 2016), I have: fossil version -v This is fossil version 2.5 [f4a9df4dd0] 2017-12-23 04:21:41 UTC Compiled on Dec 27 2017 13:45:17 using msc-19.11 (64-bit) And I can run it as a service: fossil winsrv show fossil Service name ...: fossil Display name ...: fossil Service description : Fossil - Distributed Software Configuration Management Service type ...: Service runs in its own process. Service start type .: Started automatically by the service control manager. Binary path name ...: "C:\Tools\fossil.exe" server --repolist "I:/fossil" Service username ...: LocalSystem Current state ..: Running. On another computer (which is 2012 R2), the exact same binary fails to run as a service: fossil winsrv show fossil Service name ...: fossil Display name ...: fossil Service description : Fossil - Distributed Software Configuration Management Service type ...: Service runs in its own process. Service start type .: Started automatically by the service control manager. Binary path name ...: "C:\Develop\Fossil\fossil.exe" server --repolist "C:/Develop/Fossil" Service username ...: LocalSystem Current state ..: Stopped. It is not started because upon attempt to start it, it fails and stops. Attempting to start it by "fossil winery start fossil" displays dots endlessly. But I have no clue as to what this happens without any kind of log of what might go wrong. The Event Viewer simply confirms it started and then failed to start (or stop). Running "C:\Develop\Fossil\fossil.exe" server --repolist "C:/Develop/Fossil" from a command-line is OK though. Indeed the configuration is not rigorously the same between both machines, the paths where fossil.exe is located (along with the repository) are different. But that doesn't look suspect. So what would you suggest I look for? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Import --svn "internal error: out of memory"
> Le 27 déc. 2017 à 13:22, Olivier Mascia <o...@integral.be> a écrit : > >> But the fossil import turned short after about 3200 revisions (and about 10 >> minutes too) as such: >> >> C:\Develop\Fossil>fossil import --svn integral.fossil integral.dump >> Importing SVN revision: 3203 >> Fossil internal error: out of memory >> >> What could I do from here to overcome this or, before that, better identify >> what might be the reason for "out of memory"? >> This is fossil version 2.4 [a0001dcf57] 2017-11-03 09:29:29 UTC. >> >> The computer I'm running it on for now is a VM with 4 GB RAM which could be >> easily reconfigured for much more, even if only temporarily, but as I >> understand the fossil.exe I have downloaded from fossil-scm.org is a 32-bits >> process, so should not benefit much. >> >> Should I see to build my own copy of fossil, as a 64-bits process first and >> simply retry? >> Or are there other paths to walk first? > > Considering that the dump file out of svnadmin is probably 'portable' across > platforms, and that the fossil pre-built binary for Mac is logically 64 bits, > I moved the dump file to my MacBook Pro where I'm currently re-running the > import. > > So far it has imported past the point where it failed on Windows (did about > 1/3 of the revisions for now). > > $ fossil import --svn integral.fossil integral.dump > Importing SVN revision: 6393 > > I'll report wether it went OK up the end or not and wether I seem to have > issues using fossil (32 bits) on Windows on such a repository afterwards. Success. $ fossil import --svn integral.fossil integral.dump Importing SVN revision: 15678 Done! Rebuilding repository meta-data... 100.0% complete... Vacuuming... ok And in between, while import running on Mac, I built a 64 bits binary on Windows, out of the latest trunk obtained by cloning the fossil repository, which went flawlessly (at least apparently, but I have confidence) and I now have there: This is fossil version 2.5 [f4a9df4dd0] 2017-12-23 04:21:41 UTC Compiled on Dec 27 2017 13:45:17 using msc-19.11 (64-bit) I think I should be covered for my further tests and discoveries, even though this is now latest unreleased trunk code. :) -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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] Import --svn "internal error: out of memory"
> Le 27 déc. 2017 à 12:44, Olivier Mascia <o...@integral.be> a écrit : > > Dear, > > Being "rookie" with Fossil, I'm starting some tests to migrate some of our > subversion repositories to Fossil and have a better test bed to learn fossil > before eventually deciding on a switch. > > I have successfully migrated a rather small (and secondary) repository with > only some hundreds of revisions. > So decided to run the same test on our main one. > The dump file (out of svnadmin) is about 12.6 GB, which I guess is not that > large and holds about 15600 revisions to a rather large number of files > (>27000 files, >1300 folders/subfolders). It has the usual structure of > trunk, branches, tags, with few branches and few tags. > > The svnadmin dump ran quickly (matter of <10 minutes with option -M 512). > > But the fossil import turned short after about 3200 revisions (and about 10 > minutes too) as such: > > C:\Develop\Fossil>fossil import --svn integral.fossil integral.dump > Importing SVN revision: 3203 > Fossil internal error: out of memory > > What could I do from here to overcome this or, before that, better identify > what might be the reason for "out of memory"? > This is fossil version 2.4 [a0001dcf57] 2017-11-03 09:29:29 UTC. > > The computer I'm running it on for now is a VM with 4 GB RAM which could be > easily reconfigured for much more, even if only temporarily, but as I > understand the fossil.exe I have downloaded from fossil-scm.org is a 32-bits > process, so should not benefit much. > > Should I see to build my own copy of fossil, as a 64-bits process first and > simply retry? > Or are there other paths to walk first? Considering that the dump file out of svnadmin is probably 'portable' across platforms, and that the fossil pre-built binary for Mac is logically 64 bits, I moved the dump file to my MacBook Pro where I'm currently re-running the import. So far it has imported past the point where it failed on Windows (did about 1/3 of the revisions for now). $ fossil import --svn integral.fossil integral.dump Importing SVN revision: 6393 I'll report wether it went OK up the end or not and wether I seem to have issues using fossil (32 bits) on Windows on such a repository afterwards. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Import --svn "internal error: out of memory"
Dear, Being "rookie" with Fossil, I'm starting some tests to migrate some of our subversion repositories to Fossil and have a better test bed to learn fossil before eventually deciding on a switch. I have successfully migrated a rather small (and secondary) repository with only some hundreds of revisions. So decided to run the same test on our main one. The dump file (out of svnadmin) is about 12.6 GB, which I guess is not that large and holds about 15600 revisions to a rather large number of files (>27000 files, >1300 folders/subfolders). It has the usual structure of trunk, branches, tags, with few branches and few tags. The svnadmin dump ran quickly (matter of <10 minutes with option -M 512). But the fossil import turned short after about 3200 revisions (and about 10 minutes too) as such: C:\Develop\Fossil>fossil import --svn integral.fossil integral.dump Importing SVN revision: 3203 Fossil internal error: out of memory What could I do from here to overcome this or, before that, better identify what might be the reason for "out of memory"? This is fossil version 2.4 [a0001dcf57] 2017-11-03 09:29:29 UTC. The computer I'm running it on for now is a VM with 4 GB RAM which could be easily reconfigured for much more, even if only temporarily, but as I understand the fossil.exe I have downloaded from fossil-scm.org is a 32-bits process, so should not benefit much. Should I see to build my own copy of fossil, as a 64-bits process first and simply retry? Or are there other paths to walk first? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
