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 Aug 16 06:01, Warren Young wrote:
> 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.

Maybe the reason is because subversion didn't use SQLite before?
This change only took place with the update from subversion 1.6 to
1.7.

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

This behaviour breaks concurrency with other Cygwin executables
using POSIX calls for file locking.

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

So, are you saying that Cygwin should use mandatory file locking?
You are aware that there's no chance at all to implement the UNIX
locking API calls correctly this way since Windows locking has nothing
in common with UNIX locking except for the word "locking".

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

Stop right here.  If the compatibility with native WIndows tools is more
important than the compatibility with POSIX and CYgwin POSIX tools with
each other, then why do we bother at all to implement POSIX calls in the
most POSIXy or Linuxy way possible?  Every time you don't use the Cygwin
POSIX API in favor of a native Windows call, you're breaking compatibility
with other Cygwin tools.

That's not how it's supposed to be, as far as I'm concerned...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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