Greetings, David Rothenberger!
Mikko Rapeli wrote:
As a workaround, I copied a full cygwin directory from another machine
where subversion-perl is working with svn 1.7.10 packages, and this works.
I'm glad you got it working.
With latest cygwin packages, including subversion 1.8,
perl -e
On a 10 min old cygwin installation:
$ git svn rebase
Can't load
'/usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/auto/SVN/_Ra/_Ra.dll'
for module SVN::_Ra: No such file or directory at
/usr/lib/perl5/5.14/i686-cygwin-threads-64int/DynaLoader.pm line 190.
at /usr/lib/perl5
Mikko Rapeli wrote:
On a 10 min old cygwin installation:
$ git svn rebase
Can't load
'/usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/auto/SVN/_Ra/_Ra.dll'
for module SVN::_Ra: No such file or directory at
/usr/lib/perl5/5.14/i686-cygwin-threads-64int/DynaLoader.pm line 190
It was just brought to my attention[1] that Jari's svn-load package is
(and always has been) missing a crucial dependency, pysvn (not to be
confused with subversion-python). I have python-pysvn and python3-pysvn
in Ports; should I move these to the distro, or remove svn-load?
Yaakov
[1
Il 7/7/2013 8:24 AM, Yaakov (Cygwin/X) ha scritto:
It was just brought to my attention[1] that Jari's svn-load package is
(and always has been) missing a crucial dependency, pysvn (not to be
confused with subversion-python). I have python-pysvn and python3-pysvn
in Ports; should I move
Pawel Jasinski wrote:
hi,
after recent update I noticed a problem with 'git svn'
first, it was complaining about 'address already taken'
After restart and rebaseall I am getting:
$ git svn rebase
Current branch master is up to date.
error: git-svn died of signal 6
I can confirm this:
$ git
Christian Franke wrote:
Pawel Jasinski wrote:
hi,
after recent update I noticed a problem with 'git svn'
first, it was complaining about 'address already taken'
After restart and rebaseall I am getting:
$ git svn rebase
Current branch master is up to date.
error: git-svn died of signal 6
I
On 2013-07-06 07:27, Chloe wrote:
How do I install the latest SVN? I have version
$ svn --version
svn, version 1.7.8 (r1419691)
compiled Jan 26 2013, 10:45:51
$ which svn
/usr/bin/svn
but my working copy is a newer format:
$ svn info
svn: E155021: This client is too old to work
On 7/5/2013 10:27 PM, Chloe wrote:
How do I install the latest SVN? I have version
$ svn --version
svn, version 1.7.8 (r1419691)
compiled Jan 26 2013, 10:45:51
$ which svn
/usr/bin/svn
I tried setup.exe and searched in
http://cygwin.mirrors.hoobly.com
http://box-soft.com
ftp
How do I install the latest SVN? I have version
$ svn --version
svn, version 1.7.8 (r1419691)
compiled Jan 26 2013, 10:45:51
$ which svn
/usr/bin/svn
but my working copy is a newer format:
$ svn info
svn: E155021: This client is too old to work with the working copy at
I tried setup.exe
Hi,
I also noticed the perl package errors and did a reinstall of all perl packages
with setup.exe. Did not help.
Then in desperation I did a few reboots and rebaseall's and suddenly the
problem is gone. Sigh.
Somehow this is triggered by Windows 7 security updates but now again
everything with
(sorry, not subscribed so reply might be a bit off)
I found only one cygwin1.dll on the system. Did a rebaseall but problem stays.
Problem reproduces also when PATH=/bin so I guess this is
something else. bash, git etc binaries work well and only git svn
has this issue.
Cygwin Configuration
On 6/17/2013 10:45 AM, Mikko Rapeli wrote:
On Mon, Jun 17, 2013 at 05:00:47PM +0300, Mikko Rapeli wrote:
Has anyone else seen these when using git svn or other perl programs
on cygwin 1.7.20?
snip
$ git svn rebase
...
0 [main] perl 4424 child_info_fork::abort: address space needed
On 6/18/2013 3:28 AM, Mikko Rapeli wrote:
Missing file:
/usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll from
package perl
perl 5.14.2-3 Incomplete
Maybe reinstalling the perl package will help?
--
Larry
Hi,
Has anyone else seen these when using git svn or other perl programs
on cygwin 1.7.20?
Sometimes these go away after reboot and rebaseall. These happen mostly on
my jenkins build server running 64bit Windows 7, especially after Windows
security updates, but another 32bit machine seems
On Mon, Jun 17, 2013 at 05:00:47PM +0300, Mikko Rapeli wrote:
Has anyone else seen these when using git svn or other perl programs
on cygwin 1.7.20?
snip
$ git svn rebase
...
0 [main] perl 4424 child_info_fork::abort: address space needed by
'_Client.dll' (0x52) is already
Mikko Rapeli wrote:
On Mon, Jun 17, 2013 at 05:00:47PM +0300, Mikko Rapeli wrote:
Has anyone else seen these when using git svn or other perl programs
on cygwin 1.7.20?
snip
$ git svn rebase
...
0 [main] perl 4424 child_info_fork::abort: address space needed by
'_Client.dll
/config file.
2. http://subversion.apache.org/docs/release-notes/1.8.html#bdb-deprecated
The Berkeley back-end has been deprecated, in favour of FSFS. You may
recall that I reported some difficulty in getting Cygwin svn to work
reliably with the Berkeley DB back-end:
http://www.cygwin.com/ml
On 6/13/2013 11:54, David Stacey wrote:
http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking
I'd bet that change just makes it more important that all programs
fighting over the DB play by the same locking rules.
2.
On 1/7/2013 10:01 AM, Adam Dinwoodie wrote:
When attempting an svn export specifying a destination UNC path, I'm
seeing the export unexpectedly fail.
Thanks for the report. I'll take a look as soon as I have time, although
that may not be for a little while.
--
David Rothenberger daver
On 2012-12-05 20:24, Burton Samograd wrote: bartels
bart...@mailme.ath.cx writes:
Is there way to specify to svn on the command line or though a config
file that these types of files should automatically have executable
permissions?
svn propset svn:executable *your file
Any idea why
Csaba Raduly rcs...@gmail.com writes:
Hi Burton,
On Thu, Dec 6, 2012 at 2:24 AM, Burton Samograd wrote:
bartels bartels@.. writes:
http://cygwin.com/acronyms/#PCYMTNQREAIYR
Is there way to specify to svn on the command line or though a config
file that these types of files should
Windows will not run or (in the case of .dll's) load these files until I
do a 'chmod +x' on each of them. Why I would need to set the excutable
bit on Windows is escaping me, but it things work after I figured out I
need to do that step.
Is there way to specify to svn on the command line or though
Is there way to specify to svn on the command line or though a config
file that these types of files should automatically have executable
permissions?
svn propset svn:executable *your file
Bartels.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http
Greetings, bartels!
Is there way to specify to svn on the command line or though a config
file that these types of files should automatically have executable
permissions?
svn propset svn:executable *your file
Either that, or let Windows manage ACL's.
--
WBR,
Andrey Repin (anrdae
bartels bart...@mailme.ath.cx writes:
Is there way to specify to svn on the command line or though a config
file that these types of files should automatically have executable
permissions?
svn propset svn:executable *your file
Any idea why this has to be done with the command line version
PACKAGE DESCRIPTION
===
Homepage: http://packages.debian.org/svn-load
License : Custom (AS IS)
A free replacement for svn_load_dirs, an enhanced import facility for
Subversion. The utility will commit a single changeset that alters a
repository subtree to match a local
PACKAGE DESCRIPTION
===
Homepage: http://packages.debian.org/svn-load
License : Custom (AS IS)
A free replacement for svn_load_dirs, an enhanced import facility for
Subversion. The utility will commit a single changeset that alters a
repository subtree to match a local
On Sep 28 22:08, marco atzeri wrote:
On 9/22/2012 9:08 PM, Jari Aalto wrote:
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/svn-load/setup.hint \
http://cante.net/~jaalto/tmp/cygwin/svn-load/svn-load-1.3-1-src.tar.bz2
\
http
On 9/22/2012 9:08 PM, Jari Aalto wrote:
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/svn-load/setup.hint \
http://cante.net/~jaalto/tmp/cygwin/svn-load/svn-load-1.3-1-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/svn-load/svn-load
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/svn-load/setup.hint \
http://cante.net/~jaalto/tmp/cygwin/svn-load/svn-load-1.3-1-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/svn-load/svn-load-1.3-1.tar.bz2
Included in Debian:
http
hi,
when trying to use git-svn, message containing Can't locate
Term/ReadKey.pm in @INC ... comes up.
After locating and installing package containing ReadKey.pm everything is ok.
I suspect there is a missing dependency between git-svn package and
perl_vendor package.
Cheers
Pawel
--
Problem
Hello,
after updating Cygwin, git svn fails with the following message:
Password for 'ibr': Can't locate Term/ReadKey.pm in @INC (@INC contains:
/usr/lib/perl5/site_perl/5.10
/usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int
/usr/lib/perl5/site_perl/5.14
/usr/lib/perl5/vendor_perl/5.14
? SVN is dynamically linked to SQLite, so a
recompile isn't necessary unless the ABI for SQLite changes, right?
I was just recalling your -3 and -4 packages, rebuilt after my last
SQLite release, partly to see if rebuilding would fix the svn+sqlite
problems. You are right that that might not have
On 07.08.2012 18:30, Andrey Repin wrote:
Subversion libraries supposed to be linked directly, not used through svn
command-line wrapper.
For more details, go read http://svn-book.org/
Quite obviously, you never attempted to support a diverse user basis
(just think of all the platforms
On 8/7/2012 1:16 AM, Jochen Wiedmann wrote:
from what I can tell, a user of CygWin SVN has no possibilities to be
aware of the fact that it is indeed CygWin SVN, and not another program.
This is the root cause for problems like
http://jira.codehaus.org/browse/SCM-213
As the volunteer
Hi,
I apologize if I didn't pick the proper mailing list, but discussion
about packages sounded right to me...
from what I can tell, a user of CygWin SVN has no possibilities to be
aware of the fact that it is indeed CygWin SVN, and not another program.
This is the root cause for problems
On Tue, Aug 07, 2012 at 10:16:07AM +0200, Jochen Wiedmann wrote:
Hi,
I apologize if I didn't pick the proper mailing list, but discussion
about packages sounded right to me...
cygwin-apps: a subscriber-only list for discussing packaging issues
regarding applications that are distributed
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.
from what I can tell, a user of CygWin SVN has no possibilities to be
aware of the fact that it is indeed CygWin SVN, and not another program.
$ which svn
/usr/bin/svn
I guess is very clear
This is the root cause for problems like
http://jira.codehaus.org/browse/SCM-213
(This is about
On 07.08.2012 11:45, marco atzeri wrote:
I do not understand why you need different file for cygwin.
You gave the answer just below, Marco:
Commit on cygwin should follow cygwin rules (unix like),
so something like
SAG Consulting Services GmbH - Sitz/Registered office: Uhlandstraße
Subversion daily.
To all extents and purposes, Cygwin SVN behave just the way I'd expect
from it.
It checkout, export, import, commit without a thought or hesitation.
Moreover, I'm using it transparently on Win and Linux systems (my $HOME is on
Linux raid, mounted to Windows as network share
On 07.08.2012 12:27, Andrey Repin wrote:
To all extents and purposes, Cygwin SVN behave just the way I'd expect
from it.
I didn't say, it behaves wrong. My point is that I need to know that I
am using it, and not another svn, if all I know is there's a svn binary
in my path.
Jochen
Jochen Wiedmann wrote:
I didn't say, it behaves wrong. My point is that I need to know that I
am using it, and not another svn, if all I know is there's a svn binary
in my path.
This isn't Subversion's responsibility; the problem is more general: how do you
tell if the version of awk, sed or vim
On Mon, Aug 6, 2012 at 10:21 PM, Warren Young war...@etr-usa.com 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
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
your
of different things that could make a difference to an executable's
behaviour)?
I don't know about more general. However, I know very well that
there's a particular project (Maven Release Plugin), which has this very
problem with svn, not with awk, sed, or whatever. And I'd like to
fix that specific
Greetings, Jochen Wiedmann!
To all extents and purposes, Cygwin SVN behave just the way I'd expect
from it.
I didn't say, it behaves wrong. My point is that I need to know that I
am using it, and not another svn, if all I know is there's a svn binary
in my path.
For what reason?
Also
other of a
myriad of different things that could make a difference to an executable's
behaviour)?
I don't know about more general. However, I know very well that-
there's a particular project (Maven Release Plugin), which has this very-
problem with svn, not with awk, sed, or whatever. And I'd
On 8/7/2012 10:16 AM, Jochen Wiedmann wrote:
And, besides, your proposed solution won't work: I could, of course,
use which, or where to deduce the location of svn, but what would
that tell me. Assuming, I get /usr/bin/svn, then I'd know that which
is a CygWin binary (because it emits a CygWin
Greetings, Jochen Wiedmann!
I don't know about more general. However, I know very well that
there's a particular project (Maven Release Plugin), which has this very
problem with svn,
Then this is problem of Maven.
Subversion libraries supposed to be linked directly, not used through svn
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
Essentials' Real Time scanning turned on.
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
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
On Mon, Aug 6, 2012 at 9:09 PM, Warren Young war...@etr-usa.com 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
On 8/6/2012 7:55 PM, Michael Gundlach wrote:
On Mon, Aug 6, 2012 at 9:09 PM, Warren Young war...@etr-usa.com 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
)
despite not having TortoiseSVN installed nor having Microsoft Security
Essentials' Real Time scanning turned on.
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
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
the ones in the build
directory at least sometimes during the tests and if they are either not present
or from a different version of svn things are falling apart. If I find a way to
have it always use the newly built libraries instead (or at least the ones
installed in $DESTDIR) I'll send a patch
the libraries installed on the system rather than the ones in the build
directory at least sometimes during the tests and if they are either not present
or from a different version of svn things are falling apart. If I find a way to
have it always use the newly built libraries instead (or at least
marco atzeri marco.atzeri at 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
On 7/11/2012 9:47 AM, Achim Gratz wrote:
marco atzeri marco.atzeri at 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
Achim Gratz Stromeko at 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?
the ldd output for
your _Core.dll?
% ldd /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/SVN/_Core/_Core.dll
ntdll.dll = /c/Windows/SysWOW64/ntdll.dll (0x772f)
kernel32.dll = /c/Windows/syswow64/kernel32.dll (0x74ae)
KERNELBASE.dll = /c/Windows/syswow64
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
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
ntdll.dll
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 on, and
-cygwin/auto/SVN/_Core/_Core.dll
ntdll.dll = /c/Windows/SysWOW64/ntdll.dll (0x772f)
[...]
cygsvn_diff-1-0.dll = /usr/bin/cygsvn_diff-1-0.dll (0x67df)
??? = ??? (0x77)
Hmm. This is an installed version of the same library, not the one from
the build directory
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
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 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 TSVN icon
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.
There
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
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 could
/swig/perl/native/blib/arch/auto/SVN/_Core/_Core.dll
ntdll.dll = /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x772e)
kernel32.dll = /cygdrive/c/Windows/system32/kernel32.dll (0x75c6)
KERNELBASE.dll = /cygdrive/c/Windows/system32/KERNELBASE.dll
(0x756b
On 6/27/2012 7:06 AM, Achim Gratz wrote:
Achim Gratz Stromeko at 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
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
be
traced where exactly in SQLite this is happening (must be at least two
places, maybe more).
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
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
it.
David Rothenberger, I'd appreciate if you could try to do another build
of svn and tell us if there are any test regressions w.r.t to your last
build.
The point of the rebuild is to see if building against the latest
sqlite3 package fixes the problem?
Either that or maybe whether
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, executing
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
interesting if you
could debug where it hits that roadblock in svn. 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. Note that SQLite isn't really designed for concurrent access
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
advisory and cooperative, whereas Windows gives you mandatory
locks by default in a lot of cases. Mandatory locks allow one process
(e.g. TortoiseSVN) to deny another (e.g. Cygwin svn) the ability to
change a file, indefinitely.
Cygwin should (and apparently does) abstract away that difference
Cygwin instead of direct to the Win32 API could be
tickling BLODA bugs.
Yet another possibility is that the build option changes cause a subtle
ABI change that will be fixed when SVN is rebuilt against it.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http
that force more I/O
calls to go through Cygwin instead of direct to the Win32 API could be
tickling BLODA bugs.
Yet another possibility is that the build option changes cause a subtle
ABI change that will be fixed when SVN is rebuilt against it.
Also, I don't think I'm running any A/V software (Windows
SVN is rebuilt against it.
I've rolled my machine back to to .3 and I'll see if it fixes my system
too. Unfortunately, I'm not able to reproduce the problem *at all* this
morning with any version of anything. I guess I'll wait and see for now.
--
Problem reports: http://cygwin.com
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
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
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
-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 from 1.7.14 to 1.7.15,
but I can't say
-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've noticed cygwin svn getting a LOT of errors during
On Thu, May 24, 2012 at 02:18:50PM +0200, Corinna Vinschen wrote:
On May 24 11:22, Denis Excoffier wrote:
I've decided to use rebase/rebaseall/autorebase. Until now, i had
always run Setup download and Setup install separately, with removal
of .../release/_autorebase/* between the two
On 5/25/2012 2:17 PM, Denis Excoffier wrote:
My experience showed that my personal fork errors were never solved by
autorebasing. In my case, autorebasing brought difficulties with xz
that i don't understand and difficulties with my ~100
home-built DLLs (ie i would have to rebase them also, but
On May 25 14:17, Denis Excoffier wrote:
976945 [main] date 3440 pinfo::thisproc: myself dwProcessId 3440
767021 [main] date 3440 time: 1337945628 = time(0)
--- Process 3440, exception C005 at 610DDC3C
13438364 [main] date 3440 exception::handle: In cygwin_except_handler
On Fri, May 25, 2012 at 02:31:18PM +0200, marco atzeri wrote:
On 5/25/2012 2:17 PM, Denis Excoffier wrote:
My experience showed that my personal fork errors were never solved by
autorebasing. In my case, autorebasing brought difficulties with xz
that i don't understand and difficulties with
On Fri, May 25, 2012 at 02:54:14PM +0200, Corinna Vinschen wrote:
On May 25 14:17, Denis Excoffier wrote:
976945 [main] date 3440 pinfo::thisproc: myself dwProcessId 3440
767021 [main] date 3440 time: 1337945628 = time(0)
--- Process 3440, exception C005 at 610DDC3C
On May 25 15:18, Denis Excoffier wrote:
On Fri, May 25, 2012 at 02:54:14PM +0200, Corinna Vinschen wrote:
On May 25 14:17, Denis Excoffier wrote:
976945 [main] date 3440 pinfo::thisproc: myself dwProcessId 3440
767021 [main] date 3440 time: 1337945628 = time(0)
---
On May 25 16:52, Corinna Vinschen wrote:
On May 25 15:18, Denis Excoffier wrote:
On Fri, May 25, 2012 at 02:54:14PM +0200, Corinna Vinschen wrote:
On May 25 14:17, Denis Excoffier wrote:
976945 [main] date 3440 pinfo::thisproc: myself dwProcessId 3440
767021 [main] date
101 - 200 of 529 matches
Mail list logo
