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: <502D3A5C.7010500@etr-usa.com>
Date: Thu, 16 Aug 2012 12:22:20 -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-L <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> <502CE120 DOT 4050900 AT etr-usa DOT com> <20120816122654 DOT GG17546 AT calimero DOT vinschen DOT de> <502D1967 DOT 7090705 AT etr-usa DOT com> <20120816160656 DOT M21257 AT ds DOT net>
In-Reply-To: <20120816160656.M21257@ds.net>
Content-Type: text/plain; charset=ISO-8859-1; 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 10:34 AM, Brian Wilson wrote:
>
> Corina

Corinna.

> is correct, Cygwin is supposed to be a Posix compliant environment

It's also supposed to interoperate with native Windows programs.

> If you want to use Windoze tools, why are you using Cygwin?

First, instant 100 point credibility penalty for being puerile.

Second, the whole reason for using Cygwin is so you could have a 
Linux/POSIX environment *on Windows.*  If you have no need for Windows 
programs and want a Cygwin-like environment, wouldn't you be running 
Linux, or a BSD, or OS X, or Solaris, or...?

Okay, so you come back saying something about how there should be some 
Chinese Wall between the Cygwin and native Windows lands.  In that case, 
I recommend you install one of the above-named OSes in a VM.  It'll be 
faster and more featureful.

I'm actually struggling to come up with a reason why you would *ever* 
run Cygwin if you didn't ever want it to touch the native Windows side 
of things, or vice versa.  I guess it uses less RAM and starts up faster 
than a VM....

> you really must, why not set up Apache under Cygwin and access the Cygwin
> Subversion repository through the defined http server interface and the
> issue of file locking becomes moot.

1. That wouldn't provide all the features some people want.  TortoiseSVN 
provides a really nice version tree and a spiffy graphical diff 
facility, for example.

2. As David said, we're not talking about locks in the repository itself 
here.  We're talking about a lock on the .svn/wc.db file at the top of 
the client-side checkout tree, introduced in svn 1.7.

> As a worst case scenario, why can't the direct SVN access locking behavior
> be determined by setting an environment variable.

Because there's no easy way to do that.

You can't compile SQLite for *both* for Windows and Unix at the same 
time.  The code simply isn't structured to let you swap I/O subsystems 
in and out like that.

I could instead disentangle Windows, Cygwin and Unix in the SQLite code, 
and make the Cygwin code switch-hit between locking methods.  But keep 
in mind, the only reason I maintain the SQLite package is that I know 
what it is and how to test it, so I rescued it from being removed from 
the Cygwin distro back when its previous maintainer abandoned it.  I 
simply don't care enough about it to bother with such a big rewrite.  It 
doesn't help that upstream has ignored multiple requests to integrate 
trivial patches for it.  I expect they'd be certain to ignore a big one 
like this, so I'd then have to keep tracking upstream changes to 
reintegrate it each time.

Bottom line, the only options open to you while I'm maintainer are 
trivial patches and build system changes.

I suppose I could release *two* versions of SQLite, one for each build 
method.  I'd still nominate the Windows-aware version as the default.

I'm not sure setup.exe's dependency resolution code can cope with this, 
however.  I don't recall hearing anything about features like RPM's 
"Provides", which lets two different package provide a given facility, 
interchangeably.  If not, then the nonstandard package would have to be 
made available for manual download only, to be unpacked by hand and kept 
up to date by hand each time setup.exe overwrites it with a new version. 
  Blech.

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