X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.9 required=5.0	tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,TW_SV
X-Spam-Check-By: sourceware.org
Message-ID: <502CE120.4050900@etr-usa.com>
Date: Thu, 16 Aug 2012 06:01:36 -0600
From: Warren Young <warren AT etr-usa DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Promote sqlite 3.7.13-1 from test status?
References: <announce DOT 5029275C DOT 4040009 AT etr-usa DOT com> <502C0B7D DOT 10909 AT etr-usa DOT com> <loom DOT 20120816T092134-266 AT post DOT gmane DOT org> <20120816085016 DOT GB5536 AT calimero DOT vinschen DOT de> <502CCBB1 DOT 2070600 AT etr-usa DOT com> <20120816105507 DOT GD17546 AT calimero DOT vinschen DOT de>
In-Reply-To: <20120816105507.GD17546@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT 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