On 8/7/2012 11:32 AM, David Rothenberger wrote:
On 8/6/2012 7:21 PM, Warren Young wrote:
Some time after *that*, at a future time entirely up to the Subversion
packages' maintainer, David Rothenberger, Subversion will be rebuilt
against those new SQLite packages.
Is that actually necessary? SV
On 8/6/2012 7:21 PM, Warren Young wrote:
> Some time after *that*, at a future time entirely up to the Subversion
> packages' maintainer, David Rothenberger, Subversion will be rebuilt
> against those new SQLite packages.
Is that actually necessary? SVN is dynamically linked to SQLite, so a
recomp
Christopher,
On Tue, Aug 7, 2012 at 12:07 AM, Christopher Faylor wrote:
>>Is the snapshot that cgf is testing going to roll back svn to SQLite
>>3.7.3?
>
> Huh? No. I really have to point out that the Cygwin DLL != SQLite?
I'm not familiar with the snapshot process, and I didn't realize from
yo
On Mon, Aug 6, 2012 at 10:21 PM, Warren Young wrote:
>>> What reason could there be for a new Cygwin DLL to be accompanied by a
>>> new
>>> version of SQLite? Their maintainerships are entirely decoupled.
>>
>> Pardon my ignorance; I'm not familiar with the release process.
>
> Well, to a first a
On 8/6/2012 11:06 PM, Achim Gratz wrote:
Warren Young writes:
I think I've given Achim Gratz enough time to try and fix the bug
resulting from his build option changes.
I cannot fix something that I can't even reproduce.
I gave you some ideas of ways to reproduce it without TortoiseSVN. Did
Warren Young writes:
> I think I've given Achim Gratz enough time to try and fix the bug
> resulting from his build option changes.
I cannot fix something that I can't even reproduce. I can however
reproduce the bug that led to and fixed by those changes. As said
before, if someone has an idea h
On Mon, Aug 06, 2012 at 08:40:10PM -0400, Michael Gundlach wrote:
>Hello,
>
>On Fri, 15 Jun 2012, Warren Young wrote:
>> tl;dr: someone made the problem go away by rolling my recent 3.7.12 release
>> back to the prior 3.7.3 version.
>
>I also have this problem (on a new Win7x64 machine with an SS
On 8/6/2012 7:55 PM, Michael Gundlach wrote:
On Mon, Aug 6, 2012 at 9:09 PM, Warren Young wrote:
Is the snapshot that cgf is testing going to roll back svn to SQLite
3.7.3?
What reason could there be for a new Cygwin DLL to be accompanied by a new
version of SQLite? Their maintainerships are
On Mon, Aug 6, 2012 at 9:09 PM, Warren Young wrote:
>> Is the snapshot that cgf is testing going to roll back svn to SQLite
>> 3.7.3?
>
> What reason could there be for a new Cygwin DLL to be accompanied by a new
> version of SQLite? Their maintainerships are entirely decoupled.
Pardon my ignora
On 8/6/2012 6:40 PM, Michael Gundlach wrote:
I'd be happy to revert SQLite to 3.7.3 and work around the problem.
However, I am unable to revert SQLite from 3.7.12 to 3.7.3, because I
get an svn error after doing that: "SQLite compiled for 3.7.12, but
running with 3.7.3". Cygwin setup offers me
Hello,
On Fri, 15 Jun 2012, Warren Young wrote:
> tl;dr: someone made the problem go away by rolling my recent 3.7.12 release
> back to the prior 3.7.3 version.
I also have this problem (on a new Win7x64 machine with an SSD)
despite not having TortoiseSVN installed nor having Microsoft Security
On 7/11/2012 9:47 AM, Achim Gratz wrote:
marco atzeri gmail.com> writes:
a solution for testing is to add the new directory as first in the PATH.
I think it already tries to do that, I'll have to check more closely if it's
missing some directories or if the order is perhaps wrong. It may als
marco atzeri gmail.com> writes:
> a solution for testing is to add the new directory as first in the PATH.
I think it already tries to do that, I'll have to check more closely if it's
missing some directories or if the order is perhaps wrong. It may also be that
the Ruby and Perl dynaloaders ign
On 7/11/2012 8:33 AM, Achim Gratz wrote:
David Rothenberger acm.org> writes:
The tests work for me, but I've never been able to get them to work
without first installing the newly built packages.
After some more investigations, this is because the dynamic linker seems to use
the libraries ins
David Rothenberger acm.org> writes:
> The tests work for me, but I've never been able to get them to work
> without first installing the newly built packages.
After some more investigations, this is because the dynamic linker seems to use
the libraries installed on the system rather than the ones
On 6/28/2012 2:35 PM, Achim Gratz wrote:
I can't easily test this myself
since I don't have TortoiseSVN installed
Me, too, but it seems to me that there's a better way to find the
problem than trying to replicate the problem reporters' exact
environment. That's too complicated. The leading
David Rothenberger writes:
> I make two packages, one for 5.10 and one for 5.14. There's a separate
> patch that's required for 5.14. Did you include it? The source package
> for -4 includes it automatically.
Yes, I worked from the -4 package on one machine and the -3 package on
the other.
> Ther
On 6/28/2012 10:37 AM, Rolf Campbell wrote:
> On 2012-06-27 14:17, David Rothenberger wrote:
>> Anyway, I'll have a new release available shortly built against the
>> latest SQLite package, so others that want to use TortoiseSVN can try it.
>
> I just upgraded to the -5 package, and turned the TSV
Warren Young writes:
>> Now, if somebody could find out _where_ in SQLite it fails...
>
> Is it not true that you're the only one in many years of SQLite's
> availability in Cygwin who wanted it compiled the way it currently is?
Well yes, since one couldn't use temporary databases unless you have
On 6/28/2012 1:11 PM, Achim Gratz wrote:
Rolf Campbell writes:
On 2012-06-27 14:17, David Rothenberger wrote:
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.
I just upgraded to the -5 package, and tu
On 6/28/2012 12:04 PM, Achim Gratz wrote:
> David Rothenberger writes:
>>> I can't seem to get this working. There are a few warnings, but nothing
>>> that
>>> would explain such a massive fail. Would you mind posting the ldd output
>>> for
>>> your _Core.dll?
>>
>> % ldd /usr/lib/perl5/vendor_
Rolf Campbell writes:
> On 2012-06-27 14:17, David Rothenberger wrote:
>> Anyway, I'll have a new release available shortly built against the
>> latest SQLite package, so others that want to use TortoiseSVN can try it.
>
> I just upgraded to the -5 package, and turned the TSVN icon caching
> back o
David Rothenberger writes:
>> I can't seem to get this working. There are a few warnings, but nothing that
>> would explain such a massive fail. Would you mind posting the ldd output for
>> your _Core.dll?
>
> % ldd /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/SVN/_Core/_Core.dll
> nt
On 2012-06-27 14:17, David Rothenberger wrote:
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.
I just upgraded to the -5 package, and turned the TSVN icon caching back
on, and it very quickly failed i
On 6/28/2012 4:49 AM, Achim Gratz wrote:
> Achim Gratz nexgo.de> writes:
>>> Strange. It works for me and the ldd output for _Core.dll is reasonable.
>
> I can't seem to get this working. There are a few warnings, but nothing that
> would explain such a massive fail. Would you mind posting the
Achim Gratz nexgo.de> writes:
> > Strange. It works for me and the ldd output for _Core.dll is reasonable.
I can't seem to get this working. There are a few warnings, but nothing that
would explain such a massive fail. Would you mind posting the ldd output for
your _Core.dll?
> > Yaakov's cha
David Rothenberger writes:
> Strange. It works for me and the ldd output for _Core.dll is reasonable.
What version of autotools, swig etc. are you using? The only swig
wrappers that work for me are those for Python. Both Ruby and Perl seem
to die on those strangely non-functional DLL the build h
On 6/27/2012 7:06 AM, Achim Gratz wrote:
> Achim Gratz nexgo.de> writes:
>> I'm not near my work machine, so this is from memory... the test suite
>> requires perl modules I didn't have installed and fails most perl tests
>> without them — not too worried about this, will install those later this
Achim Gratz nexgo.de> writes:
> I'm not near my work machine, so this is from memory... the test suite
> requires perl modules I didn't have installed and fails most perl tests
> without them — not too worried about this, will install those later this
> week.
The fail is not due to a module miss
Achim Gratz wrote:
> David Rothenberger writes:
> > I'm not sure that me running the test suite will prove much, so I'll
> > make the rebuild available as a test release in case someone that was
> > experiencing the problem would like to try it out.
>
> Thanks, that should help as well if the OP co
David Rothenberger writes:
> The cygport file should check for all required build dependencies. If
> you find one missing, please let me know.
I'm not near my work machine, so this is from memory... the test suite
requires perl modules I didn't have installed and fails most perl tests
without the
On 6/26/2012 9:45 AM, Achim Gratz wrote:
> Achim Gratz writes:
> I've tried to re-build svn against the new SQLite library, but I'm not
> sure if that works correctly on my machine (the tests are still runnning
> and I get some test failures already since apparently I'm still missing
> some depende
Achim Gratz writes:
> Cygwin should (and apparently does) abstract away that difference. But
> it seems that the locking strategy might be slightly different between
> Win32 and POSIX, triggering a foray into that "disk I/O error" branch.
> There may still be a bug some place else, i.e. it may get
Warren Young writes:
>> Note that SQLite isn't really designed for concurrent access
>> to the database file from a different process.
>
> There is a paucity of truth in that statement.
So let me re-formulate that sentence: concurrent access ultimately
relies on the file locking provided by the OS
On 6/19/2012 3:18 PM, Achim Gratz wrote:
I suspect that svn
does not deal with the file being locked exclusively (when TortoiseSVN
accesses the database) and some call through the windows interface
blocked.
It's possible svn has a timer on the call that results in a SQL call
through SQLite, a
Rolf Campbell writes:
> I would hate to add TortoiseSVN to the BLODA.
The icon cache _is_ dodgy — at least the one for TortoiseGit, which
needs to be restarted regularly.
But getting back to SQLite, backing out the changes in the build would
get us back a different bug. So it would be very inter
On 2012-06-19 05:29, Adam Dinwoodie wrote:
Rolf Campbell wrote:
$ svn up
Updating '.':
svn: E200030: disk I/O error, executing statement 'RELEASE s6'
svn: E200030: sqlite: unable to open database file
svn: E200030: sqlite: unable to open database file
$ svn cleanup
svn: E200030: disk I/O erro
Rolf Campbell wrote:
> Recently, I've noticed cygwin svn getting a LOT of errors during
> operations. I think this started when upgrading from 1.7.14 to 1.7.15,
> but I can't say for sure. The nature of these errors are as follows:
>
> $ svn up
> Updating '.':
> svn: E200030: disk I/O error, exe
On 2012-06-15 06:37, Warren Young wrote:
It is indeed AV related -- a race between SQLite and AV
That's one possibility, but check this out:
http://stackoverflow.com/questions/11007024/
tl;dr: someone made the problem go away by rolling my recent 3.7.12
release back to the prior 3.7.3 ve
On 2012-06-15 06:37, Warren Young wrote:
On 6/14/2012 4:00 PM, Garrison, Jim (ETW) wrote:
Why would you think that a disk I/O error was either anti-virus or
Cygwin related and not... a disk I/O error? Have you looked in your
event logs for errors?
It is indeed AV related -- a race between SQL
On 6/14/2012 4:00 PM, Garrison, Jim (ETW) wrote:
Why would you think that a disk I/O error was either anti-virus or
Cygwin related and not... a disk I/O error? Have you looked in your
event logs for errors?
It is indeed AV related -- a race between SQLite and AV
That's one possibility, but c
> -Original Message-
> Subject: RE: cygwin 1.7.15: svn disk I/O error
>
> > -Original Message-
> > Subject: Re: cygwin 1.7.15: svn disk I/O error
> >
> > On Thu, Jun 14, 2012 at 03:48:05PM -0400, Rolf Campbell wrote:
> > >Recently, I
> -Original Message-
> Subject: Re: cygwin 1.7.15: svn disk I/O error
>
> On Thu, Jun 14, 2012 at 03:48:05PM -0400, Rolf Campbell wrote:
> >Recently, I've noticed cygwin svn getting a LOT of errors during
> >operations. I think this started when upgrading fr
On 2012-06-14 15:55, Christopher Faylor wrote:
On Thu, Jun 14, 2012 at 03:48:05PM -0400, Rolf Campbell wrote:
$ svn cleanup
svn: E200030: disk I/O error, executing statement 'RELEASE s79'
Sometimes the errors happen, sometimes not. It seems to be about 50% of
the time svn has this type of
On Thu, Jun 14, 2012 at 03:48:05PM -0400, Rolf Campbell wrote:
>Recently, I've noticed cygwin svn getting a LOT of errors during
>operations. I think this started when upgrading from 1.7.14 to 1.7.15,
>but I can't say for sure. The nature of these errors are as follows:
>
>$ svn up
>Updating '.
Recently, I've noticed cygwin svn getting a LOT of errors during
operations. I think this started when upgrading from 1.7.14 to 1.7.15,
but I can't say for sure. The nature of these errors are as follows:
$ svn up
Updating '.':
svn: E200030: disk I/O error, executing statement 'RELEASE s6'
46 matches
Mail list logo
