Re: Promote sqlite 3.7.13-1 from test status?

[Warren Young <warren@etr-usa.com>]

On 8/16/2012 4:55 AM, Corinna Vinschen wrote:
> On Aug 16 04:30, Warren Young wrote:
>>
>> So, what you did with that requested change, Achim, is prevented
>> Cygwin svn from winning any fights over ownership of .svn/wc.db.
>
> So what?  Don't use native Windows tools in parallel accessing the
> same file.  Full stop.

I've been maintaining the Cygwin SQLite package for four years now. 
This recent wish for SQLite on Cygwin to act more Unix-like is the first 
such request I've received, and I don't remember it being an issue with 
the previous maintainer, either.

But, shortly after making the change -- because I didn't immediately see 
why it would hurt anything -- complaints started pouring in from actual 
people who've been doing what you say they shouldn't do.

So what's a package maintainer to do?  Go all WJM on them? :)

I don't see why I should break previously working behavior just out of 
purity, given that, so far, only one person ever in the entire world has 
been bothered enough by that lack of purity to ask me to change how 
SQLite is compiled.

> Why should mandatory locking be better here, while it's quite naturally
> using advisory locking in the entire UNIX world?

Because that's what a native Windows build of SQLite does.

(Why?  Because https://sqlite.org/faq.html#q5)

Advisory locking only works when all players cooperate.  We can't assume 
that on Windows, unless we set up an insular Cygwin ghetto.

> If you think it's absolutely necessary to use some Windows
> functions, what is it, and why?

The scenario is this:

Dev Fred likes to use the GUI TortoiseSVN client most of the time. 
(Fred is a little strange, but we like him anyway.)

There is no Cygwin port of TortoiseSVN, because it is a deeply 
Windows-native program, doing things like adding a shell extension to 
Windows Explorer.  There is also no Cygwin GUI SVN client we can 
recommend people use instead, and even if there were, you can imagine a 
lot of people would push back, given the consequent requirement for X11.

On occasion, Fred runs into a situation where the GUI can't do a given 
task, or at least can't do it as well as you can from the command line. 
  What are Fred's options?

Option 1: Download the native Windows Subversion port.  Sensible, but it 
means you have to use a crippled shell.

Option 2: Install Cygwin and add the svn package, so you have a 
reasonable command line environment.

Why should Option 2 result in incorrect behavior, when the correct fix 
is known and -- much more important -- already implemented upstream?

Maybe you didn't realize that last, Corinna: Cygwin SQLite is built 
pretty much stock OOTB.  There's just one minor patch I make, which 
replaces a deprecated Cygwin 1.5 DLL call with its v1.7 replacement. 
Aside from ifdefs and such, it's about as stock a build as you could 
wish.  It's not like I'm patching a bunch of Windowsisms into the 
upstream source purely for Cygwin's sake.

Upstream's already made the call.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple