On Thu, Jul 25, 2013 at 03:46:21PM +0200, Jan Nijtmans wrote:
> 2013/7/25 Richard Hipp <d...@sqlite.org>:
> > If it does work, then I move for the immediate banishment of all __CYGWIN__
> > macros.
> Doing that will break four things:
> - Accessing a check-out repository on Cygwin, while the previous check-out
>   was done in win32.
> - Allow usage of win32 paths (possibly coming from WIN32 variables) in fossil.
> - Cygwin doesn't allow '\' in paths like UNIX does, or the behavior of
> UNC paths.
> - Cooperation of Cygwin with windows programs using sqlite (like TortoiseSVN)

As a cygwin user, this breakage is what I expect by any cygwin version of a
program, be it fossil, mercurial, git, vim, ...

I'd never use a cygwin-git checkout with non-cygwin-git, for example. I never
tried and i would not expect it to work.

> > If it doesn't work, is that a bug in cygwin?
> More likely, it's a limitation of Cygwin running on Windows.
> Not seconded.
> In SQLite various __CYGWIN__ #ifdef's can be removed if another locking
> mechanism is put in place. Attached is the current patch the Cygwin
> people use for their build of SQLite accomplishing this. But this only
> works on Cygwin > 1.7.20, and it doesn't follow the SQLite coding
> style, so it will need some more work.

I have no idea how locking has to be handled in cygwin, but if the issue is at
using a sqlite db with both cygwin and non-cygwin programs, this is a tricky

As for me, I don't expect cygwin programs' data to cope well with windows
programs' data.

fossil-users mailing list

Reply via email to