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
thing.

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

Regards,
Lluís.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to