Mail Archives: cygwin/2012/08/16/14:23:49
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
- Raw text -