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


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