I propose to release Fossil version 2.10 sometime around 2019-10-10 or shortly thereafter - as soon as SQLite version 3.30.0 final is available to be built into the Fossil sources. Objections?

I think the change log is mostly up-to-date. Please correct me if I have overlooked anything of consequence.

Would it be helpful if I provided pre-compiled betas on the Download page?

Why the major version jump? Or was that a typo? The change log says 2.10.

That was a typo. I have now fixed it. (If you are just now reading this thread - the original post said "Fossil version 3.10" instead of "Fossil version 2.10".)

Why no v3.0?

The semantic versioning rule is that the first number only changes when there is an incompatible API change. This happened for 1.37 → 2.0 due to the addition of SHA3 hashes. But since then, there have only been fully backwards compatible enhancements, so we are still on 2.x.

Would it be helpful if I provided pre-compiled betas on the Download page?

I think that's a good idea! You provide betas of SQLite for folks to try out, so I think doing the same in Fossil is smart.

Would it be helpful if I provided pre-compiled betas on the Download page?

+1

There are several open branches with recent changes that need a resolution: fix, merge, or reject:

• skin-cap-matching: I think this one is simply correct, and should be merged. But, since it affects the default skin, which means it affects fossil-scm.org, it needs a resolution from a higher power than me.

• private-branches: Not my itch at all, but it looks like good work. Is it complete and merge-able, Florian?

• windows-tools: Also not my itch, but it seems harmless. In my opinion, pure additions outside the main code base like this one can go straight to trunk.

• iis-cgi: I haven't bothered testing this one, even though I'm the one who wrote the IIS CGI guide, because I don't actually care whether Fossil can be run in CGI mode under IIS. I only wrote the guide because I assumed the answer was, "Yes, of course it can." When it failed, I checked in what I wrote with the hope that someone who cared about the issue would take over and solve the problem; and lo, tsbg claims to have done so! So, drh, can we just merge this branch and remove the warning from the guide? I'd merge it myself, but my understanding of the way Fossil handles CGI is fuzzy, and I don't want to break normal CGI use with a careless merge.

There is now a precompiled binary for Win64 on the Download page.

This is my first attempt to compile a 64-bit binary for Windows. It is built using OpenSSL-1.1.1d and MSVC. Please give it a try. If I get positive feedback, this is the delivery format that I will use moving forward. But if there are issues, I'll revert to using a 32-bit build based on Mingw32.

Is it too late to introduce a fix in git export for Windows?

The first action of this command is to execute git init 'X:/path/to/repo', with single quotes. This is correct in UN*X, but it fails in Windows (git init aborts with an error indicating Invalid argument).

For Windows, using double quotes as in git init "X:/path/to/repo" works correctly, even for paths with spaces.

Patch added at https://fossil-scm.org/fossil/info/be7c1bde92c8caae

I wonder if what we should actually do is try to find and call the POSIX shell included in the "Git for Windows" distributions in the #if defined(_WIN32) fork of fossil_system() so we get consistent cross-platform command interpretation. If we fail to find that shell, then we can take the current alternative of calling _wsystem(), which is documented to call the stunningly-weak cmd.exe for command interpretation.

It'd be a fair bit more work than just ifdef'ing the quoting style, but maybe it'd be worth it?

With the current logic, you can have double quotes in file names but not single quotes, whereas ifdef'd quoting styles would effectively mean you can't have either quote in some file names in a repo that will be used across platforms.

Consider:

  $ fossil init '"I Make Life Hard for Myself Sometimes," said Warren.fossil'
  $ f all sync

And on testing it, I see that we fail that case today:

  ...lots of happy success...
  fossil sync -autourl -R 
  unknown repository: -R

So when someone bothers to fix that quote-passing case, it'll be fixed for POSIX OSes only under the current scheme, and it'll still be broken for Windows unless we take this portable fossil_system() option.

And that, among other reasons, is why PowerShell is no answer to this problem.

To answer one obvious objection, "How do you know when you've found a portable sh.exe?" I answer that it should be possible to construct a simple test using this pseudocode as a model:

  if (popen2("sh -c 'echo hi'", ...) == 0 &&
      strncmp(result, "hi", 2) == 0) {
    /* it's a POSIX shell */ 
  }

Maybe an enhancement for 2.11. For 2.10 lets make the reasonable assumption that the user does not have double-quotes in any component of their pathname for the GIT repository.

I wonder if what we should actually do is try to find and call the POSIX shell included in the "Git for Windows" distributions in the #if defined(_WIN32) fork of fossil_system()

Is it worth it? Does it work? I have Git for Windows installed, but git-cmd.exe and git-bash.exe are not in the PATH nor in the AppPath entries in the registry, and so they're not directly invokable from the command line. I have an alias to invoke git-cmd.

If we fail to find that shell, then we can take the current alternative of calling _wsystem(), which is documented to call the stunningly-weak cmd.exe for command interpretation.

Does it call cmd.exe directly, or whatever shell is pointed by the COMSPEC envvar? Some of us have replacements for cmd, you know.

If you are running minGit I don't believe you get any shells included with Git for Windows.

Some tests and thoughts on this interesting topic:

It seems not even the mingw32 build of git.exe for Windows supports single-quoted arguments. Session transcript from CMD.EXE:

> mingw32\bin\git config --global --replace-all user.name "'Mona' Lisa"
> mingw32\bin\git config --global user.name
'Mona' Lisa
> mingw32\bin\git config --global --replace-all user.name '"Mona" Lisa'
> mingw32\bin\git config --global user.name
'Mona
> fossil test-echo 'single quotes' "double quotes"
g.nameOfExe = [...]
argv[0] = [fossil]
argv[1] = [test-echo]
argv[2] = ['single]
argv[3] = [quotes']
argv[4] = [double quotes]

The Windows git-bash.exe shell rewrites single-quoted arguments to double-quoted arguments, suitable for Win32 programs. Session transcript from git-bash.exe:

> mingw32/bin/git config --global --replace-all user.name "'Mona' Lisa"
> mingw32/bin/git config --global user.name
'Mona' Lisa
> mingw32/bin/git config --global --replace-all user.name '"Mona" Lisa'
> mingw32/bin/git config --global user.name
"Mona" Lisa
> fossil test-echo 'single quotes' "double quotes"
g.nameOfExe = [...]
argv[0] = [...]
argv[1] = [test-echo]
argv[2] = [single quotes]
argv[3] = [double quotes]

With the correct quoting rules, the same result can be achieved from CMD.EXE:

...
> mingw32\bin\git config --global --replace-all user.name "\"Mona\" Lisa"
> mingw32\bin\git config --global user.name
"Mona" Lisa
...

Even though a dependency on a POSIX-compliant shell on Windows may be optional for Fossil, it seems somewhat clumsy to use such a shell just to perform correct command-line argument quoting, when the same is possible without any intermediate step.

I've posted a summary about Win32 command-line argument quoting:

[fossil-forum]: Quoting command-line arguments on Windows

I've written a QuoteArgvW() function with 72 test cases to properly quote any individual Win32 command-line argument. Together with Fossil's useful blob/string buffer manipulation functions, this could be used for a function to convert any argv[] array to a concatenated Win32 command-line string, to ensure proper parsing by the Win32 C runtime library of the child process, or by the CommandLineToArgvW() Win32 API function.

Since there seemed to be little or no interest in fixing this, I haven't done more work, and not contributed anything in this direction ...

... because, in reality, it probably doesn't matter: Configuring a web server to call Fossil as CGI to serve repositories with quotes in their file names (in both repository: or directory: mode) may be very tricky, if not impossible, due to limitations imposed by the web server, and by Fossil itself.

To me, support for repository file names with double-quotes seems like something that can be neglected. In fact, even for my customized version of Fossil, the only thing that I've "pseudo-fixed" (i.e. it would break with embedded double-quotes, or trailing backslashes) is the forwarding of the --page option argument from fossil ui to the web browser, so that the URL query string argument separator & reaches the web browser, instead of acting as a command separator and breaking the web browser command-line.

Just for completeness: the output of a simple Win32 dumpcmd scratch program to dump the command line using GetCommandLineW(), invoked from git-bash.exe:

> dumpcmd "'Mona' Lisa\\" '"Mona" Lisa\\'
...\mingw32\bin\dumpcmd.exe "'Mona' Lisa\\" "\"Mona\" Lisa\\\\"

So git-bash.exe does nothing special, but applies the quoting rules for Win32 command-line arguments.

I forgot to mention (or, repeat) the most important thing: double quotes are not valid in file names on Windows. So quoting file names as command-line arguments by enclosing them in double quotes would work for almost all cases -- unless the file name (or, in this case the directory name) ends with a trailing backslash, which would escape the closing double quote.

Fossil version 2.10 has been tagged and precompiled binaries are now available on the website.

Hi! Can you make 32-bit version Fossil V.2.10. on Download page?

On my 32-bit Windows 7 host, I wanted to upgrade from 2.8 and noticed that 2.10 is only available in x64.

https://www.fossil-scm.org/fossil/uv/download.html

Is the 32-bit Windows binary not available?

Source code is available, which will compile cleanly on Windows7 using either mingw or MSVC. So you can build your own. But, no, prebuilt 32-bit binaries are no longer provided for any platform.

Any reason? Any issues to expect? Note that all kind of Raspberry Pi & friends are still ususally operated by 32 bit operating systems/distributions, even the new Raspberry 4 (although the CPU and the hardware capabilities would of course allow to install a 64 bit system).

There are no issues to expect, but availability of 32-bit platforms to build on has been in decline the past decade, as has their footprint in the user base.

For anyone running a Pi/Pine/Beagle/etc., it is generally assumed (by me, anyway! ;) that they know how to compile software for it, as that's a common need on such systems.

(Edit: missing word)

Thanks for the info.

Can I use the DM compiler instead?

How should I compile the zlib library before trying to build a Fossil Win32 binary? As a DLL, or just object files?

" download the zlib source. unzip it and compile " https://www.fossil-scm.org/fossil/wiki?name=compillingOnWindows

I tried compiling Fossil using the zlib "Developer files" 1.2.3 binary lib + h files from 20 July 2005 from http://gnuwin32.sourceforge.net/packages/zlib.htm :

Since the forum strips backslash symbols, I pasted the output here:

https://pastebin.com/raw/r9aucvnV

Next, I tied Mingw, and after ~20 mn of compiling:

https://pastebin.com/raw/DTrtxKgS

Next, tried with Pelles C compiler:

https://pastebin.com/raw/pYHUE4Me

Next, tried MSVC Community 2019… and failed.

Here's the output: https://pastebin.com/raw/tykZZwfK

Has anyone successfully compiled Fossil 2.10 as Win32?

To check that it wasn't linked to the recent decision to no longer provide a 2.10 binary, I tried compiling 2.8 with Digital Mars, and have the same error:

"Cannot open file [builtin_data.h]" https://pastebin.com/raw/cKYAuvxb

Compiling 2.8 with Mingw also fails, so it looks like there's something missing either in the instructions or how I installed Mingw:

"src/winhttp.c:799:57: error: 'NO_ERROR' undeclared (first use in this function)" https://pastebin.com/raw/X1X8YHpN

I have no problems compiling 32 bit.

You need to be running VCVARS32.BAT to set up your environment instead of just adding the directory with nmake to your path.

In your MSVC installation in your Start menu, look for something like "x86 Native Tools Command Prompt".

Thanks, it was the missing piece in the instructions.

I simply…

1. Launched Start > All Programs > Visual Studio 2019 > Visual Studio Tools > Developer Command Prompt for VS 2019
2. Ran "cd c:srcfossil-2.10win ; nmake /f Makefile.msc"

Still, MSVC is such a beast: Any idea what is missing in the instructions to compile Fossile Win32 with lighter compilers such as Digital Mars or Mingw?

That page hasn't been updated in more than 7 years. There are briefer and newer instructions at:

https://fossil-scm.org/home/wiki?name=Release+Build+How-To

Is there something else I should type to compile with Mingw?

1. Open a DOS box
2. C:\MinGW\msys\1.0\msys.bat
3. $ cd c:/src/fossil-2.10
4. $ make clean -f win/Makefile.mingw
5. $ make -f win/makefile.mingw
mkdir -p wbld
c:/src/fossil-2.10/make -C src/../compat/zlib PREFIX= CC=gcc LOC="-DASMV -        DASMIN
F" OBJA="inffas86.o match.o" -f win32/Makefile.gcc libz.a
c:\src\fossil-2.10\make: invalid option -- A
c:\src\fossil-2.10\make: invalid option -- M
Usage: make [options] [target] ...

Found it: While investigating the issues above, I copied GNU's make-3.81 in the Fossil directory. It looks like Mingw's make has more features; Removing GNU's make to let Mingw use its own solved the issue.

It went a lot further, but still fails.

Could it be due to that feature about Fossil and Windows services?

…
gcc -Wall -Wdeclaration-after-statement -Os -Lsrc/../compat/zlib -Isrc/../compat
/zlib -DBROKEN_MINGW_CMDLINE=1 -DFOSSIL_ENABLE_LEGACY_MV_RM=1  -I. -Isrc -o wbld
/wikiformat.o -c wbld/wikiformat_.c
gcc -Wall -Wdeclaration-after-statement -Os -Lsrc/../compat/zlib -Isrc/../compat
/zlib -DBROKEN_MINGW_CMDLINE=1 -DFOSSIL_ENABLE_LEGACY_MV_RM=1  -I. -Isrc -o wbld
/winfile.o -c wbld/winfile_.c
gcc -Wall -Wdeclaration-after-statement -Os -Lsrc/../compat/zlib -Isrc/../compat
/zlib -DBROKEN_MINGW_CMDLINE=1 -DFOSSIL_ENABLE_LEGACY_MV_RM=1  -I. -Isrc -o wbld
/winhttp.o -c wbld/winhttp_.c
src/winhttp.c: In function 'win32_http_service_ctrl':
src/winhttp.c:802:57: error: 'NO_ERROR' undeclared (first use in this function)
       win32_report_service_status(SERVICE_STOP_PENDING, NO_ERROR, 0);
                                                         ^~~~~~~~
src/winhttp.c:802:57: note: each undeclared identifier is reported only once for
 each function it appears in
src/winhttp.c: In function 'win32_http_service_main':
src/winhttp.c:837:50: error: 'NO_ERROR' undeclared (first use in this function)
     win32_report_service_status(SERVICE_STOPPED, NO_ERROR, 0);
                                                  ^~~~~~~~
src/winhttp.c: In function 'win32_http_service_running':
src/winhttp.c:864:50: error: 'NO_ERROR' undeclared (first use in this function)
     win32_report_service_status(SERVICE_RUNNING, NO_ERROR, 0);
                                                  ^~~~~~~~
src/winhttp.c: In function 'win32_http_service':
src/winhttp.c:896:25: error: 'ERROR_FAILED_SERVICE_CONTROLLER_CONNECT' undeclare
d (first use in this function)
     if( GetLastError()==ERROR_FAILED_SERVICE_CONTROLLER_CONNECT ){
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/winhttp.c: In function 'cmd_win32_service':
src/winhttp.c:1167:27: error: 'ERROR_SERVICE_MARKED_FOR_DELETE' undeclared (firs
t use in this function)
       if( GetLastError()==ERROR_SERVICE_MARKED_FOR_DELETE ){
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/winhttp.c:1220:37: error: 'ERROR_INSUFFICIENT_BUFFER' undeclared (first use
in this function)
     if( !bStatus && GetLastError()!=ERROR_INSUFFICIENT_BUFFER ){
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [wbld/winhttp.o] Error 1

Edit : Indeed, searching *.h for "NO_ERROR" returns no hit. Does compiling Fossil with Mingw require adding some include files from elsewhere?

Edit: Found what it was.

1. copy c:\MinGW\include\winerror.h c:\src\fossil-2.8\wbld\
2. Edit src/winhttp.c: Add #include "winerror.h"
3. make -f win/Makefile.mingw

c:\src\fossil-2.10>fossil version
This is fossil version 2.10 [9d9ef82234] 2019-10-04 21:41:13 UTC

I checked the wiki but found no infos on how to edit (add/edit) a document.

This document needs to be updated.

I checked the wiki but found no infos on how to edit (add/edit) a document.

The wiki is not publicly editable - it requires a developer's account.

If the information in the "building a release" doc is sufficient, or could be made so without making it "unduly verbose," i propose that we replace the contents of the long-unmaintained "compiling on windows" doc with a link to the "building a release" doc.

This one?

In that's the case, here's my take:

Windows 32-bit

1. Download MinGW, install in c:\mingw, and choose mingw32-base + msys-base
2. Update the user/sytem PATH to include c:\mingw\bin;c:\mingw\msys\1.0\bin
3. Download the latest Fossil source code, and unzip in eg. c:\src\fossil
4. (Needed to compile 2.10; Still required?) copy c:\mingw\include\winerror.h c:\src\fossil\wbld
5. (Needed to compile 2.10; Still required?) Edit src\winhttp.c: Add #include "winerror.h"
6. Open a DOS box, and run C:\mingw\msys\1.0\msys.bat to switch to a Mingw shell
7. cd c:/src/fossil
8. make -f win/Makefile.mingw

CHECK

If you want SSL support:

1. Download Openssl, and unzip in c:\MingW
2. ?Compile?
3. ?make -f Makefile.w32 FOSSIL_ENABLE_SSL=1 LIB="-lssl -lcrypto -lgdi32 -lmingwex -lz -lws2_32" OR make -f win/makefile.mingw FOSSIL_ENABLE_SSL=1 OPENSSLDIR=../../openssl-1.0.1t