On Fri, Jun 14, 2024 at 5:19 PM Roland Mainz wrote:
>
> On Fri, Jun 14, 2024 at 12:14 PM Mark Liam Brown
> wrote:
> > Cygwin 3.4/3.5 svn fails on a NFS4 share during checkout
> >
> > svn checkout https://svn.FreeBSD.org/base/head/share/man
> > Aman/man4
>
On Fri, Jun 14, 2024 at 12:14 PM Mark Liam Brown
wrote:
> Cygwin 3.4/3.5 svn fails on a NFS4 share during checkout
>
> svn checkout https://svn.FreeBSD.org/base/head/share/man
> Aman/man4
> Aman/man4/tcp.4
> Aman/man4/ndis.4
> Aman/man4/Makefile
> Ama
Greeting!
Cygwin 3.4/3.5 svn fails on a NFS4 share during checkout
svn checkout https://svn.FreeBSD.org/base/head/share/man
Aman/man4
Aman/man4/tcp.4
Aman/man4/ndis.4
Aman/man4/Makefile
Aman/man4/altq.4
Aman/man4/miibus.4
Aman/man4/vlan.4
Aman/man4/ng_macfilter.4
ry for release automation.
>> I already do some massaging to a similar extent, but a proper alternatives
>> support would be much more convenient.
>>
>> Thank you in advance.
>>
>>
> Hi Andrey
> what exactly do you mean ?
> is you need svn to point to another
be much more convenient.
Thank you in advance.
Hi Andrey
what exactly do you mean ?
is you need svn to point to another program than
/usr/bin/svn.exe
can not you set Alternatives to use a
/usr/local/bin/svn
as switch point between /usr/bin/svn.exe and your alternate ?
What am I missing
Greetings, marco atzeri!
Marco, on an unrelated note, can you please package Subversion with
alternatives support?
I understand that the request is uncommon, but I do have uncommon
requirements. I'm using a custom Subversion build, which is good for common
use, but have a small deficiency in
On 18.01.2022 18:31, Brian Inglis wrote:
On 2022-01-17 23:15, Marco Atzeri wrote:
On 18.01.2022 03:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
Submitted details for adding Cygwin packages to the Apache Subversion
Binary Packages web page:
configuration peculiarities for
Cygwin (but also,
I noticed that for some reason the source code treats Cygwin as
Windows -- particularly
how the pathname is assumed to have the drive letters, and that is
really baffling --
so I am not exactly sure what was meant by that by the SVN developers
configuration peculiarities for Cygwin (but
also,
I noticed that for some reason the source code treats Cygwin as Windows --
particularly
how the pathname is assumed to have the drive letters, and that is really
baffling --
so I am not exactly sure what was meant by that by the SVN developers).
You
peculiarities for Cygwin (but
also,
I noticed that for some reason the source code treats Cygwin as Windows --
particularly
how the pathname is assumed to have the drive letters, and that is really
baffling --
so I am not exactly sure what was meant by that by the SVN developers).
Anton
hat for some reason the source code treats Cygwin as Windows --
particularly
how the pathname is assumed to have the drive letters, and that is really
baffling --
so I am not exactly sure what was meant by that by the SVN developers).
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports
t's a Cygwin issue,
> not svn's)...
>
> I use svn at home on Cygwin via a tunneled connection to my SVN server at
> work, so when the tunnel is
> not up (and basically, svn connects to localhost:SVN-port and supposedly
> receives "connection refused"),
> it crashes u
Hi all,
Before I go ahead and try to submit this as a bug report with the Apache
Subversion project, I wanted to ask
if anybody experiences the same issue as me (or, maybe it's a Cygwin issue, not
svn's)...
I use svn at home on Cygwin via a tunneled connection to my SVN server at work,
so
Ivan Garcia Sainz-Aja writes:
> I fixed my problem with git-svn downgrading perl-Scalar-List-Utils to
> version 1.49 (instead of 1.50) from here
>
> http://mirrors.kernel.org/sourceware/cygwin/x86/release/
> perl-Scalar-List-Utils/
>
> I'm attaching the file cygcheck.o
Hi Adam
I fixed my problem with git-svn downgrading perl-Scalar-List-Utils to
version 1.49 (instead of 1.50) from here
http://mirrors.kernel.org/sourceware/cygwin/x86/release/
perl-Scalar-List-Utils/
I'm attaching the file cygcheck.out
Thanks a lot for your help
Iván García
On Tue, 22 May 2018 at 09:35, Ivan Garcia Sainz-Aja wrote:
> Hi all,
> I'm getting the following error using git-svn (I think the only change I
> made was that I updated subversion)
> ➤ git svn rebase
> Can't load
'/usr/lib/perl5/vendor_perl/5.26/i686-cygwin-threads-64int
Hi all,
I'm getting the following error using git-svn (I think the only change I
made was that I updated subversion)
➤ git svn rebase
Can't load
'/usr/lib/perl5/vendor_perl/5.26/i686-cygwin-threads-64int/auto/List/Util/Util.dll'
for module List::Util: No such process at /usr/share/perl5/5.26
Hi,
after upgrading to subversion-1.10 in cygwin, the command completion in zsh for
svn no longer works.
I don't get the same problem on Linux where the completion still works with
subversion 1.10, so to me it looks like something cygwin-specific, but I can't
be sure. I don't know if I should
On 16/01/2017 20:26, Jon Turney wrote:
> On 16/01/2017 20:07, Sam Edge wrote:
>> On 09/01/2017 19:07, Sam Edge wrote:
>>> On 09/01/2017 02:04, Eliot Moss wrote:
>>>> On 1/8/2017 3:45 PM, David Rothenberger wrote:
>>>>> On 1/8/2017 6:12 AM, Sam Edge wrot
On 16/01/2017 20:07, Sam Edge wrote:
On 09/01/2017 19:07, Sam Edge wrote:
On 09/01/2017 02:04, Eliot Moss wrote:
On 1/8/2017 3:45 PM, David Rothenberger wrote:
On 1/8/2017 6:12 AM, Sam Edge wrote:
I've seen a number of 'svn segfault' threads on the mailing list
archive
but none of them seem
On 09/01/2017 19:07, Sam Edge wrote:
> On 09/01/2017 02:04, Eliot Moss wrote:
>> On 1/8/2017 3:45 PM, David Rothenberger wrote:
>>> On 1/8/2017 6:12 AM, Sam Edge wrote:
>>>> I've seen a number of 'svn segfault' threads on the mailing list
>>>> a
On 1/8/2017 3:45 PM, David Rothenberger wrote:
On 1/8/2017 6:12 AM, Sam Edge wrote:
I've seen a number of 'svn segfault' threads on the mailing list archive
but none of them seem to cover this specific failure mode. (Apologies if
one of them does!)
I'm getting segfaults from svn but only when
On 08/01/2017 20:45, David Rothenberger wrote:
On 1/8/2017 6:12 AM, Sam Edge wrote:
[...]
I've attached cygcheck & the segfault stackdump.
I'm at a loss. Any ideas?
[Cygwin subversion maintainer here.]
Sorry, I have no further ideas. svn+ssh is working fine for me here
using both Cy
On 1/8/2017 6:12 AM, Sam Edge wrote:
I've seen a number of 'svn segfault' threads on the mailing list archive
but none of them seem to cover this specific failure mode. (Apologies if
one of them does!)
I'm getting segfaults from svn but only when using ssh as the schema.
The following three
On Wed, Mar 09, 2016 at 07:46:06PM +, Adam Dinwoodie wrote:
> On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
> > Using the latest production release 2.4.1(1) the command is removing the
> > / after the svn: leaving svn:/svn which isn't correct. Using
> > 'sv
est production release 2.4.1(1) the command is removing the
>>>> / after the svn: leaving svn:/svn which isn't correct. Using
>>>> 'svn://svn' doesn't help either.
>>>>
>>>> (2) $ git svn init -T 'svn://svn.code.sf.net/p/squirrelmail/code/trunk'
>&
On Wed, Mar 09, 2016 at 07:56:36PM +, Adam Dinwoodie wrote:
> On Wed, Mar 09, 2016 at 07:46:06PM +, Adam Dinwoodie wrote:
> > On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
> > > Using the latest production release 2.4.1(1) the command is removing the
>
On 3/9/2016 2:56 PM, Adam Dinwoodie wrote:
> On Wed, Mar 09, 2016 at 07:46:06PM +, Adam Dinwoodie wrote:
>> On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
>>> Using the latest production release 2.4.1(1) the command is removing the
>>> / after the svn: l
On Wed, Mar 09, 2016 at 07:46:06PM +, Adam Dinwoodie wrote:
> On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
> > Using the latest production release 2.4.1(1) the command is removing the
> > / after the svn: leaving svn:/svn which isn't correct. Using
> > 'sv
On Tue, Mar 08, 2016 at 01:32:30PM -0500, cyg Simple wrote:
> Using the latest production release 2.4.1(1) the command is removing the
> / after the svn: leaving svn:/svn which isn't correct. Using
> 'svn://svn' doesn't help either.
>
> (2) $ git svn init -T 'svn://svn.code.sf.net
Using the latest production release 2.4.1(1) the command is removing the
/ after the svn: leaving svn:/svn which isn't correct. Using
'svn://svn' doesn't help either.
(1) CYGWIN_NT-10.0 HAL2002 2.4.1(0.293/5/3) 2016-01-24 11:26 x86_64 Cygwin
(2) $ git svn init -T 'svn://svn.code.sf.net/p
On Nov 14 12:59, tdotre...@aircrack-ng.org wrote:
> Hi,
>
> I just updated to cygwin 2.3.1-1 after
> https://cygwin.com/ml/cygwin/2015-11/msg00186.html1 to see if the update
> solves the issue but it still segfaults. I only tested gcc 5.2.0-1 and I'm
> pretty sure it's gonna happen on every other
Hi,
I just updated to cygwin 2.3.1-1 after
https://cygwin.com/ml/cygwin/2015-11/msg00186.html1 to see if the update
solves the issue but it still segfaults. I only tested gcc 5.2.0-1 and
I'm pretty sure it's gonna happen on every other gcc version available
since the output is exactly the
Wb Yang wrote:
> 3. I also tried to run this with gdb this afternoon. How ever, since
> the 1.9.1-1's "subversion-debuginfo" is not available from the
> setup-x86_64.exe yet, I was not able to figure out the exact exception
> source. Do you know where-else can I download a copy of the debug
>
Thanks Dave,
1. I didn't type in the command correctly, it was like "svn diff -c
12345 MY-REPO-URL";
2. Your recipe works fine here;
3. I also tried to run this with gdb this afternoon. How ever, since
the 1.9.1-1's "subversion-debuginfo" is not available from the
set
= 'yangwe'
PWD = '/cygdrive/c/svn/OlympusIoBox/IoBox_MCU/trunkC'
HOME = '/home/yangwe'
HOMEPATH = '\Users\yangwe'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man'
APPDATA = 'C:\Users\yangwe\AppData\Roaming'
ProgramW6432 = 'C:\Program Files'
HOSTNAME = 'PCSZYANGWE01'
SHELL = '/bin/bash'
TERM
Segmentation fault happens 100% when calling:
svn diff -c .
In "svn.exe.stackdump":
/
Exception: STATUS_ACCESS_VIOLATION at rip=001801
Wb Yang wrote:
> Segmentation fault happens 100% when calling:
>
> svn diff -c .
"svn diff -c ." is not a valid command. The "-c" switch expects a
numeric argument. I get an error message when I try it, not a segfault.
Does this recipe work for you?
% mkdir /tmp
On Sun, Aug 02, 2015 at 08:35:25AM +0200, Achim Gratz wrote:
The tests for 2.5.0 just completed:
--8---cut here---start-8---
fixed 1
success 12528
failed 0
broken 179
total 12808
--8---cut here---end---8---
On Sat, Aug 01, 2015 at 08:17:59PM +0200, Achim Gratz wrote:
Adam Dinwoodie writes:
I think git-svn should and used to depend on subversion-perl, but
this seems to have gone missing, somehow.
How very odd! That was one of the automatically generated
dependencies, so presumably
Adam Dinwoodie writes:
I'm going to continue to be cautious: while I think the risk of bumping
up to v2.5.0 is very low, if there are problems with that or any of the
other numerous recent changes (this has been the first time a release
has got above the -1 version since I took over
Adam Dinwoodie writes:
I'm going to look at taking the latest upstream releases once the new
version of Perl has been released; I didn't want to take a version bump
while we are also taking other changes.
The tests for 2.5.0 just completed:
--8---cut
while we are also taking other changes.
I think git-svn should and used to depend on subversion-perl, but this
seems to have gone missing, somehow.
; I didn't want to take a version bump
while we are also taking other changes.
I think git-svn should and used to depend on subversion-perl, but this
seems to have gone missing, somehow.
How very odd! That was one of the automatically generated dependencies,
so presumably the dependency
Adam Dinwoodie writes:
I think git-svn should and used to depend on subversion-perl, but
this seems to have gone missing, somehow.
How very odd! That was one of the automatically generated
dependencies, so presumably the dependency generation has just gone a
bit sideways, probably because
Adam Dinwoodie writes:
These packages are now uploaded, with a !perl file instead of a
!ready file.
Thanks.
I'm going to look at taking the latest upstream releases once the new
version of Perl has been released; I didn't want to take a version bump
while we are also taking other changes.
On Tue, Jul 28, 2015 at 07:43:56AM +0200, Achim Gratz wrote:
Adam Dinwoodie writes:
I'm just waiting for it to finish running through the test suite
before I upload :)
Thank you.
These packages are now uploaded, with a !perl file instead of a
!ready file.
I'm going to look at taking the
Perl version 5.22:
git
git-svn
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Waldorf MIDI Implementation additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
into vendor_perl and need an
update or re-release using Perl version 5.22:
git
git-svn
I'm just waiting for it to finish running through the test suite before
I upload :)
Adam Dinwoodie writes:
I'm just waiting for it to finish running through the test suite
before I upload :)
Thank you.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Wavetables for the Terratec KOMPLEXER:
:
https://cygwin.com/ml/cygwin/2013-07/msg00376.html
If this is the case I assume that the problem has little to do with svn itself
but with the cygwin-dll and should be fixed by Corinna. But, that is just my
humble guess.
Note, that I tried to give the link already in the previous mail
attempts to get UNC paths working with svn in the past,
but obviously I have not succeeded. I urge you to try to patch either
libapr1 or subversion yourself to correct the problem, if you have the
necessary coding skills. I honestly don't forsee myself having the time
or interest to fix this myself
On 4/24/2015 8:53 AM, Tobias Nähring wrote:
Hi,
I am experiencing the following problem again:
2013-07 msg00376.html
UNC paths are not recognized by svn.
The double slash at the beginning of UNC paths gets lost:
svn status -u //servername/some/path/under/svn
svn: warning: W155007
Hi,
I am experiencing the following problem again:
2013-07 msg00376.html
UNC paths are not recognized by svn.
The double slash at the beginning of UNC paths gets lost:
svn status -u //servername/some/path/under/svn
svn: warning: W155007: '/servername/some/path/under/svn ' is not a working copy
On Wed, Mar 18, 2015 at 7:45 PM, David Stacey wrote:
I have a PC with both Cygwin and TortoiseSVN.
Using both Cygwin svn and TortoiseSVN on the same repo is problematic.
Even if you don't run into locking problems, the native line-ending
differs (Cygwin's svn uses LF, TortoiseSVN uses CR LF
2015-03-19 5:01 GMT+01:00 Eric Pement eric.pem...@gmail.com:
The TortoiseSVN FAQ file, answering the question of whether one can
use different SVN clients on the same working copy, says this is not
recommended.
The FAQ mentions Cygwin in particular:
I am aware of this FAQ entry
2015-03-19 10:55 GMT+01:00 Csaba Raduly rcs...@gmail.com:
Using both Cygwin svn and TortoiseSVN on the same repo is problematic.
Even if you don't run into locking problems, the native line-ending
differs (Cygwin's svn uses LF, TortoiseSVN uses CR LF). I've had these
problems in the past
On 19/03/15 04:01, Eric Pement wrote:
On Wed, Mar 18, 2015 at 2:45 PM, David Staceydrsta...@tiscali.co.uk wrote:
I have a PC with both Cygwin and TortoiseSVN. When I try to commit through
Cygwin svn, I get the following:
... [rest omitted] ...
The TortoiseSVN FAQ file, answering
On 18/03/15 20:57, Denis Excoffier wrote:
On 2015-03-18 19:45, David Stacey wrote:
I have a PC with both Cygwin and TortoiseSVN. When I try to commit through
Cygwin svn, I get the following (slightly redacted):
Committed revision n.
svn: E20: Commit succeeded, but other errors follow
On 18/03/15 20:57, Denis Excoffier wrote:
On 2015-03-18 19:45, David Stacey wrote:
I have a PC with both Cygwin and TortoiseSVN. When I try to commit through
Cygwin svn, I get the following (slightly redacted):
Committed revision n.
svn: E20: Commit succeeded, but other errors follow
On Wed, Mar 18, 2015 at 2:45 PM, David Stacey drsta...@tiscali.co.uk wrote:
I have a PC with both Cygwin and TortoiseSVN. When I try to commit through
Cygwin svn, I get the following:
... [rest omitted] ...
The TortoiseSVN FAQ file, answering the question of whether one can
use different SVN
I have a PC with both Cygwin and TortoiseSVN. When I try to commit
through Cygwin svn, I get the following (slightly redacted):
Committed revision n.
svn: E20: Commit succeeded, but other errors follow:
svn: E155009: Error bumping revisions post-commit (details follow):
svn: E155009
On 2015-03-18 19:45, David Stacey wrote:
I have a PC with both Cygwin and TortoiseSVN. When I try to commit through
Cygwin svn, I get the following (slightly redacted):
Committed revision n.
svn: E20: Commit succeeded, but other errors follow:
svn: E155009: Error bumping
On Wed, Jan 7, 2015 at 7:14 PM, David Rothenberger wrote:
...
I no longer use Subversion, having switched to git,
Heretic!
(: Csaba :)
--
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex,
On 07/01/2015 18:14, David Rothenberger wrote:
On 1/7/2015 7:18 AM, Ken Brown wrote:
/usr/bin/svn-bisect is not in the current release of subversion-tools,
but it's in the previous release. Is this a packaging oversight or a
deliberate decision?
It was an explicit decision by me, the package
On 1/7/2015 7:18 AM, Ken Brown wrote:
/usr/bin/svn-bisect is not in the current release of subversion-tools,
but it's in the previous release. Is this a packaging oversight or a
deliberate decision?
It was an explicit decision by me, the package maintainer. The 1.7
release series had an svn
/usr/bin/svn-bisect is not in the current release of subversion-tools, but it's
in the previous release. Is this a packaging oversight or a deliberate decision?
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation
Hi,
I am sending this here and not to subversion project directly, since i
am seeing my problem in svn 1.8.1 of cygwin, but not on SVN 1.8.1 of
TortoiseSVN.
I just added a file with unicode chinese characters in a folder where
a repository is checked out. I didn't add that file to the repository
On 7/21/2014 10:15 AM, olivier barthelemy wrote:
Hi,
I am sending this here and not to subversion project directly, since i
am seeing my problem in svn 1.8.1 of cygwin, but not on SVN 1.8.1 of
TortoiseSVN.
I just added a file with unicode chinese characters in a folder where
a repository
Hi All,
I am using setup-x86_64.exe and choosing the latest SVN clients:
http://i.imgur.com/TUyRyAq.png
But after installing (and a reboot), SVN still shows up as the old version.
Sun Mar 02 - 10:26 PM svn --version
svn, version 1.7.6 (r1370777)
compiled Aug 22 2012, 15:38:04
It doesn't
Greetings, Robert Mark!
I am using setup-x86_64.exe and choosing the latest SVN clients:
http://i.imgur.com/TUyRyAq.png
But after installing (and a reboot), SVN still shows up as the old version.
Sun Mar 02 - 10:26 PM svn --version
svn, version 1.7.6 (r1370777)
compiled Aug 22 2012
/bin/svn is the old version too...
Sun Mar 02 - 11:43 PM /bin/svn --version
svn, version 1.7.6 (r1370777)
compiled Aug 22 2012, 15:38:04
On Sun, Mar 2, 2014 at 10:55 PM, Andrey Repin anrdae...@yandex.ru wrote:
Greetings, Robert Mark!
I am using setup-x86_64.exe and choosing the latest
Oh, I think I see what I have done - I seem to have both C:\cygwin64
and C:\cygwin installed. :/
On Sun, Mar 2, 2014 at 11:44 PM, Robert Mark
robertmarkbram.li...@gmail.com wrote:
/bin/svn is the old version too...
Sun Mar 02 - 11:43 PM /bin/svn --version
svn, version 1.7.6 (r1370777
Greetings, Robert Mark!
I am using setup-x86_64.exe and choosing the latest SVN clients:
http://i.imgur.com/TUyRyAq.png
But after installing (and a reboot), SVN still shows up as the old version.
Sun Mar 02 - 10:26 PM svn --version
svn, version 1.7.6 (r1370777)
compiled Aug 22 2012
subversion client (e.g. TortoiseSVN), or some anti-virus software
locking a file in the '.svn' directory (e.g. 'wc.db'). See if you can
check out into an area of the drive that isn't being virus scanned.
For years I have the same AV (MSE) and I have used SVN without
problems...
I think what
David Stacey wrote:
I think what you're seeing here is what we term a BLODA - some non-Cygwin application
interfering with a Cygwin application. In your case, if you're not running a native
Windows svn client then anti-virus is top of the suspect list. I know you claim that you
have used MSE
Information
Package VersionStatus
cygwin 1.7.25-1 OK
sqlite3 3.7.17-3 OK
subversion 1.8.3-1OK
Same here (on XP 32)...
Secondly, make sure you're using the cygwin version of 'svn' (i.e. check that
some other
On 9/29/2013 13:39, Angelo Graziosi wrote:
What is wrong with this command:
$ svn co svn://gcc.gnu.org/svn/gcc/branches/fortran-dev fortran-dev
What happens if you modify it a bit:
$ CYGWIN_SQLITE_LOCKING=posix svn co svn://...
That forces the SQLite library that Cygwin's svn is linked
Warren Young wrote:
What happens if you modify it a bit:
$ CYGWIN_SQLITE_LOCKING=posix svn co svn://...
It works for almost an hour (I started to think it was a good fix for
me...) but then it stopped in the same way... :-(
[...]
Afortran-dev/gcc/testsuite/gcc.c-torture/execute
What is wrong with this command:
$ svn co svn://gcc.gnu.org/svn/gcc/branches/fortran-dev fortran-dev
On GNU/Linux (kubuntu 12.04 64 bit) it is completed successfully but on
Cygwin (32 bit) it fails after a while in this way:
[...]
Afortran-dev/gcc/testsuite/gnat.dg
On 29/09/2013 20:39, Angelo Graziosi wrote:
What is wrong with this command:
$ svn co svn://gcc.gnu.org/svn/gcc/branches/fortran-dev fortran-dev
On GNU/Linux (kubuntu 12.04 64 bit) it is completed successfully but
on Cygwin (32 bit) it fails after a while in this way:
[...]
A fortran-dev
Currently, git-svn of Cygwin is unusable because of this:
http://git.661346.n2.nabble.com/Git-pm-with-recent-File-Temp-fail-td7580381.html
FYI, it was fixed on git 1.8.3:
https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.3.txt
--
Problem reports: http://cygwin.com
On Aug 28 11:16, David Rothenberger wrote:
Corinna Vinschen wrote:
On Aug 28 09:05, Robert Klemme wrote:
On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger
daver...@acm.org wrote:
On 8/27/2013 9:04 AM, Robert Klemme wrote:
$ svn --version /usr/bin/svn.exe: error while loading shared
On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger daver...@acm.org wrote:
On 8/27/2013 9:04 AM, Robert Klemme wrote:
$ svn --version
/usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
shared object file: No such file or directory
Check that you have libneon27 installed
On Aug 28 09:05, Robert Klemme wrote:
On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger daver...@acm.org wrote:
On 8/27/2013 9:04 AM, Robert Klemme wrote:
$ svn --version
/usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
shared object file: No such file or directory
Corinna Vinschen wrote:
On Aug 28 09:05, Robert Klemme wrote:
On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger
daver...@acm.org wrote:
On 8/27/2013 9:04 AM, Robert Klemme wrote:
$ svn --version /usr/bin/svn.exe: error while loading shared
libraries: ?: cannot open shared object file
Hi folks,
even obtaining the version fails with this:
$ svn --version
/usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
shared object file: No such file or directory
I have a pretty fresh installation (only selected the older version of
svn) and am not aware of anything I
On 8/27/2013 9:04 AM, Robert Klemme wrote:
$ svn --version
/usr/bin/svn.exe: error while loading shared libraries: ?: cannot open
shared object file: No such file or directory
Check that you have libneon27 installed. That's missing from the
dependencies. If that doesn't work, try cygcheck /usr
Hi SVN maintainer,
Is a 64-bit release going to come out soon? SVN is quite a pain to build
manually, compared with most other packages, especially if support for
SSL, etc. is configured...
Thanks!
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http
On Aug 21 12:04, Ryan Johnson wrote:
Hi SVN maintainer,
Is a 64-bit release going to come out soon? SVN is quite a pain to
build manually, compared with most other packages, especially if
support for SSL, etc. is configured...
Subversion is part of the 64 bit distro already before
On 21/08/2013 12:11 PM, Corinna Vinschen wrote:
On Aug 21 12:04, Ryan Johnson wrote:
Hi SVN maintainer,
Is a 64-bit release going to come out soon? SVN is quite a pain to
build manually, compared with most other packages, especially if
support for SSL, etc. is configured...
Subversion is part
Christian Franke wrote:
Christian Franke wrote:
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
Christian Franke wrote:
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
problem now. Performing
a svn st on a subversion working copy residing on a UNC share is
broken now.
I do get this error message:
svn: E078: Can't read directory '//server/share/path': Partial
results are valid but processing is incomplete.
When I exchange cygwin1.dll with the one from
cygcheck output from the working setup is:
Found: C:\cygwin\bin\perl.exe
Found: C:\Testwell\CTC\perl
Warning: C:\cygwin\bin\perl.exe hides C:\Testwell\CTC\perl
I wonder if this is the reason? Perhaps Cygwin was picking up the wrong
perl?
Without any perhaps.
Yes! This was the
SVN/_Ra/_Ra.dll is part of the subversion-perl package, as is
SVN/Base.pm. You have one but not the other. Do you have
There is a _Ra.dll and a Base.pm, files are there.
/usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/auto/SVN/_Ra/_Ra.dll.new?
If so, you have to reboot your
With latest cygwin packages, including subversion 1.8,
perl -e 'require SVN::Ra' works, but svn 1.8 breaks HTTPS NTML
authentication which works with 1.7.10.
Downgrading to subversion 1.7.10 worked well a few weeks back but not
anymore. Would be nice to figure out what changed.
-Mikko
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.
cygcheck output from the working setup is:
Cygwin Configuration Diagnostics
Current System Time: Mon Jul 15 11:59:04 2013
Windows 7 Enterprise Ver 6.1
Hi Mikko,
On Mon, Jul 15, 2013 at 1:20 PM, 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.
cygcheck output from the working setup is:
Cygwin Configuration Diagnostics
(snip
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 'require SVN::Ra' works
1 - 100 of 529 matches
Mail list logo
