This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Promote sqlite 3.7.13-1 from test status?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]