Re: svn crashes when connection to server refused

Greetings, Marco Atzeri! > On 26.01.2022 21:16, Andrey Repin wrote: >> 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 cust

Re: svn crashes when connection to server refused

On 26.01.2022 21:16, Andrey Repin wrote: 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 commo

Re: svn crashes when connection to server refused

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 LC_TI

Re: [EXTERNAL] Re: svn crashes when connection to server refused

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: https://subversion.apache.org/packages.html

Re: [EXTERNAL] Re: svn crashes when connection to server refused

On 2022-01-17 23:15, Marco Atzeri wrote: On 18.01.2022 03:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Subversion seems to have along list of upstream issues can you check if the issue was already noted and solved upstream ? If so I can deploy a new release. Looks like 1.14.1 dated Feb 2021

Re: [EXTERNAL] Re: svn crashes when connection to server refused

On 2022-01-17 19:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: Subversion seems to have along list of upstream issues can you check if the issue was already noted and solved upstream ? If so I can deploy a new release. Thanks for the suggestion! Looks like 1.14.1 dated Feb 2021 is

Re: [EXTERNAL] Re: svn crashes when connection to server refused

On 18.01.2022 03:03, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: Subversion seems to have along list of upstream issues can you check if the issue was already noted and solved upstream ? If so I can deploy a new release. Thanks for the suggestion! Looks like 1.14.1 dated Feb 2021 is the lat

RE: [EXTERNAL] Re: svn crashes when connection to server refused

> Subversion seems to have along list of upstream issues > > can you check if the issue was already noted and solved upstream ? > If so I can deploy a new release. Thanks for the suggestion! Looks like 1.14.1 dated Feb 2021 is the latest official release, per their website; and that's what we h

Re: svn crashes when connection to server refused

On Sun, Jan 16, 2022 at 11:55 PM Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > 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, > n

Re: svn segfault when using svn+ssh schema

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 wrote: >> I've seen a number of 'svn segfault'

Re: svn segfault when using svn+ssh schema

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 t

Re: svn segfault when using svn+ssh schema

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 to cover this specif

Re: svn segfault when using svn+ssh schema

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 u

Re: svn segfault when using svn+ssh schema

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 Cygwin an

Re: svn segfault when using svn+ssh schema

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 comm

Re: svn-bisect no longer in subversion-tools

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, wit

Re: svn-bisect no longer in subversion-tools

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 m

Re: svn-bisect no longer in subversion-tools

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

Re: svn 1.7.10-1 on x86_64 does not work

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 > >> wrote: > >>> On 8/27/2013 9:04 AM, Robert Klemme wrote: > $ svn --version /usr/bin/svn.exe: error while loading shared >

Re: svn 1.7.10-1 on x86_64 does not work

Corinna Vinschen wrote: > On Aug 28 09:05, Robert Klemme wrote: >> On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger >> 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 su

Re: svn 1.7.10-1 on x86_64 does not work

On Aug 28 09:05, Robert Klemme wrote: > On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger 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 > >

Re: svn 1.7.10-1 on x86_64 does not work

On Tue, Aug 27, 2013 at 6:14 PM, David Rothenberger 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. That's

Re: svn 1.7.10-1 on x86_64 does not work

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 /

Re: SVN::Ra problems

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

Re: SVN::Ra problems

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

Re: SVN::Ra problems

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

Re: SVN::Ra problems

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 (s

Re: SVN::Ra problems

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

Re: SVN::Ra problems

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

Re: SVN::Ra problems

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

Re: SVN::Ra problems

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

Re: SVN - Newest Version

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

Re: SVN - Newest Version

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 t

Re: svn-1.8 Release Notes

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. http://subversion.apache.org/docs/release-notes/1.8.ht

Re: 'svn export' fails when given UNC path as destination

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 da

Re: SVN and executable permissions

On 2012-12-05 20:24, Burton Samograd wrote:> bartels 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 "*" > Any idea why this has to be done wit

Re: SVN and executable permissions

Csaba Raduly writes: > Hi Burton, > > On Thu, Dec 6, 2012 at 2:24 AM, Burton Samograd wrote: >> bartelswrites: > > 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 automaticall

Re: SVN and executable permissions

bartels 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 "*" Any idea why this has to be done with the command line version of svn and not with To

Re: SVN and executable permissions

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 "*" Either that, or let Windows manage ACL's. -- WBR, Andrey Repin (anrdae...@freemai

Re: SVN and executable permissions

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 "*" Bartels. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/f

Re: svn --version

On 2012-05-25 17:26, Corinna Vinschen wrote: > 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::thispro

Re: svn --version

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

Re: svn --version

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

Re: svn --version

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 610DD

Re: svn --version

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 diffi

Re: svn --version

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_handl

Re: svn --version

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

Re: svn --version

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/* b

Re: svn --version

On Thu, May 24, 2012 at 04:51:08PM +0200, Corinna Vinschen wrote: >> On May 24 14:36, Corinna Vinschen wrote: >> > On May 24 14:18, Corinna Vinschen wrote: >> > > On May 24 11:22, Denis Excoffier wrote: >> > > > On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote: >> > > > >> On May 24

Re: svn --version

On May 24 14:36, Corinna Vinschen wrote: > On May 24 14:18, Corinna Vinschen wrote: > > On May 24 11:22, Denis Excoffier wrote: > > > On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote: > > > >> On May 24 09:06, Denis Excoffier wrote: > > > >> > > > > >> > Hello, > > > >> > > > > >>

Re: svn --version

On May 24 14:18, Corinna Vinschen wrote: > On May 24 11:22, Denis Excoffier wrote: > > On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote: > > >> On May 24 09:06, Denis Excoffier wrote: > > >> > > > >> > Hello, > > >> > > > >> > With the new subversion (1.7.5) and the last > > >> >

Re: svn --version

On May 24 11:22, Denis Excoffier wrote: > On Thu, May 24, 2012 at 10:12:02AM +0200, Corinna Vinschen wrote: > >> On May 24 09:06, Denis Excoffier wrote: > >> > > >> > Hello, > >> > > >> > With the new subversion (1.7.5) and the last > >> > snapshot (20120523 21:51:34), the command 'svn --version'

Re: svn --version

On May 24 09:06, Denis Excoffier wrote: > > Hello, > > With the new subversion (1.7.5) and the last > snapshot (20120523 21:51:34), the command 'svn --version' produces > segmentation fault, with no svn.exe.stackdump produced: > > % /usr/bin/svn --version > Segmentation fault > % I just install

Re: svn and Tortoise

Greetings, Rurik Christiansen! > Funnily enough there is no bash.bashrc or global profile or such (unlike > for csh) You can create one yourself. I did. -- WBR, Andrey Repin (anrdae...@freemail.ru) 15.04.2012, <17:31> Sorry for my terrible english... -- Problem reports: http://cygwin.c

Re: svn and Tortoise

On Fri, Apr 13, 2012 at 03:13:54PM +1000, Rurik Christiansen wrote: > > Funnily enough there is no bash.bashrc or global profile or such (unlike > for csh) You should have /etc/profile and /etc/bash.bashrc. They are part of base-files. Try 'cygcheck -l base-files'. If you don't have them in place

Re: svn and Tortoise

On 13/04/2012 14:32, Rurik Christiansen wrote: > Since updating the svn client to 1.7 I have trouble checking in, svn > just hangs. > > I also have installed the TortoiseSVN 1.7 and that one works. > > My server is ver 1.6 > > Anyone seen this or may have any clue ? Why, oh why do I see the solu

Re: svn

On 2/15/2011 3:09 AM, Gary wrote: > David Rothenberger wrote: >> On 2/14/2011 12:11 AM, Gary wrote: > >>> If I can replace svn in the sequence with something else, for example >>> tortoise, and everything then works, then Cygwin/svn *is* the culprit. >> >> If the bits are identical, then what else

Re: svn

On 2/14/2011 12:11 AM, Gary wrote: > David Rothenberger wrote: >> If the files checked out in both directories are byte-for-byte identical >> (including binary files), I can't see how svn could be the culprit. > > If I can replace svn in the sequence with something else, for example > tortoise, an

Re: svn

On 2/14/2011 9:43 AM, Gary wrote: Eliot Moss wrote: We have had occasional but persistent queries here about git over ssh, and you are reporting issues with svn and ssh. I've never mentioned ssh in this context. Ah, sorry, then. I thought perhaps it was svn+ssh that was giving you trouble. M

Re: svn

On 2/14/2011 7:25 AM, Gary wrote: Eliot Moss wrote: On 2/14/2011 3:11 AM, Gary wrote: David Rothenberger wrote: If the files checked out in both directories are byte-for-byte identical (including binary files), I can't see how svn could be the culprit. If I can replace svn in the sequence

Re: svn

On 2/14/2011 3:11 AM, Gary wrote: David Rothenberger wrote: If the files checked out in both directories are byte-for-byte identical (including binary files), I can't see how svn could be the culprit. If I can replace svn in the sequence with something else, for example tortoise, and everythin

Re: svn

On 2/11/2011 12:08 AM, Gary wrote: > David Rothenberger wrote: > >> I would diff the TortoiseSVN checkout and the Cygwin client's >> checkout. Maybe that will show you what's different and help us >> understand why. > > Well I did, and assuming I used the correct command, the differences are > on

Re: svn

So may you *should* have some auto-props, such as svn:mime-type application/octet-stream on dll files. If that is not set, it is possible that dlls will be treated in some funky way and thus when checked out again may not be byte-for-byte what you expect. I'm not sure, but I have a number of auto-

Re: svn

On 2/10/2011 11:20 PM, Larry Hall (Cygwin) wrote: On 2/10/2011 9:15 PM, Eliot Moss wrote: On 2/10/2011 3:03 PM, Gary wrote: Not sure what you mean here. You mean the mount options? Not sure what they are, I'm on a different computer right now. Yes, I think so, but there is a place where, when

Re: svn

On 2/10/2011 9:15 PM, Eliot Moss wrote: On 2/10/2011 3:03 PM, Gary wrote: Not sure what you mean here. You mean the mount options? Not sure what they are, I'm on a different computer right now. Yes, I think so, but there is a place where, when you set up cygwin, you indicate a preference for W

Re: svn

On 2/10/2011 3:03 PM, Gary wrote: Eliot Moss wrote: I wonder if it has to do with (a) what svn believes to be a text, as opposed to binary, file; Possibly. But... I shouldn't have to configure that for my svn client, should I? Isn't that supposed to be done on the repo end? Yes and no. The

Re: svn

On 2/10/2011 12:03 PM, Gary wrote: > Hmm. Well, I would hope that "svn co ." just gets whatever happens > to be in the repo - LF, CRLF, whatever - and doesn't feck with them just > because they are not the line endings some program someone might want to > sometime use, expects. Is that not the cas

Re: svn

On 2/10/2011 10:45 AM, Gary wrote: Not sure if this is a Cygwin-svn problem or just a svn-is-just-f*cked-up problem. I use the Cygwin command line interface - svn, version 1.6.15 (r1038135) compiled Nov 29 2010, 14:09:28 - and was having problems compiling a modified, checked out project, agains

Re: svn using sasl

On 9/8/2010 1:23 AM, Joël Krähemann wrote: > Hi, I don't want svn to store passwords in plain text that's why I > decided to use sasl. But I can't login anymore when changing > authentication to sasl. Below I posted some files and commands, could > someone tell me what's wrong with? I didn't test

Re: svn do nothing

On Tue, 22 Jun 2010 18:14:38 +0800, Steven Woody wrote: > Hi, > > After I upgrade my cygwin to the latest version. the 'svn' program > always returns nothing for me for any svn commands including the very > simple 'svn --version' command. It just simply return to the next > command prompt withou

Re: svn don't remember my password.

On 14.06.2010 12:35, Oleksandr Gavenko wrote: On 14.06.2010 12:22, Oleksandr Gavenko wrote: $ svn help | head -n 2 usage: svn [options] [args] Subversion command-line client, version 1.6.9. svn: Write error: Broken pipe $ cd $OLDREPO $ HOME=/cygdrive/d/tmp svn ls Authentication realm:

Re: svn don't remember my password.

On 14.06.2010 12:22, Oleksandr Gavenko wrote: $ svn help | head -n 2 usage: svn [options] [args] Subversion command-line client, version 1.6.9. svn: Write error: Broken pipe $ cd $OLDREPO $ HOME=/cygdrive/d/tmp svn ls Authentication realm: Subversion Repositories Password f

Re: "svn --version" halts in 1.7.2-2

Christopher Faylor wrote on 2010-03-28: On Sun, Mar 28, 2010 at 11:53:44AM -0400, Christopher Faylor wrote: On Sun, Mar 28, 2010 at 04:34:27PM +0200, Matthias Andree wrote: At least that would explain why I can breakpoint exit() with gdb tracing svn, and it hangs if I continue into exit(). I

Re: "svn --version" halts in 1.7.2-2

Peter Rosin wrote on 2010-03-28: It could be that /usr/lib/sasl2/libsasldb.la lists /usr/lib/libdb-4.2.la as a dependency_libs. libdb-4.2.la may or may not be installed (it's in libdb4.2-devel which I don't have installed) and if it's missing libltdl might be "confused". If that's indeed the ca

Re: "svn --version" halts in 1.7.2-2

2010/3/27 David Rothenberger : > What happens if you rename /usr/lib/sasl2 to something else? > % mv /usr/lib/sasl2 /usr/lib/sasl2.disabled > % svn --version This workaround is good. 2010/3/29 Christopher Faylor : > This should be fixed in the current snapshot at > http://cygwin.com/snapshots/ T

Re: "svn --version" halts in 1.7.2-2

On Sun, Mar 28, 2010 at 11:53:44AM -0400, Christopher Faylor wrote: >On Sun, Mar 28, 2010 at 04:34:27PM +0200, Matthias Andree wrote: >>At least that would explain why I can breakpoint exit() with gdb >>tracing svn, and it hangs if I continue into exit(). > >I can duplicate the problem and am looki

Re: "svn --version" halts in 1.7.2-2

Den 2010-03-27 17:08 skrev Charles Wilson: On 3/27/2010 11:23 AM, David Rothenberger wrote: On 3/27/2010 7:47 AM, Charles Wilson wrote: Obviously, something is going wrong there. What happens when the .la file isn't found, is that libltdl falls back on cygwin's dlopen(), which simply looks in

Re: "svn --version" halts in 1.7.2-2

On Sun, Mar 28, 2010 at 04:34:27PM +0200, Matthias Andree wrote: >At least that would explain why I can breakpoint exit() with gdb >tracing svn, and it hangs if I continue into exit(). I can duplicate the problem and am looking into it. cgf -- Problem reports: http://cygwin.com/problems.ht

Re: "svn --version" halts in 1.7.2-2

Am 27.03.2010 17:37, schrieb Andy Koppe: > Charles Wilson: >> Hmm. I remember having transient problems with svn and many of the >> 1.7.0 snapshots, but they were intermittent and I had bigger fish to >> fry. I don't recall any issues with 1.7.1, nor am I having any trouble >> with 1.7.2. Howeve

Re: "svn --version" halts in 1.7.2-2

Am 27.03.2010 03:15, schrieb Eliot Moss: > On 3/26/2010 10:12 PM, David Rothenberger wrote: >> On 3/26/2010 5:57 PM, Eliot Moss wrote: >>> My Windows 7 system hands on svn --version also, but >>> produces no messages to /var/log/messages. I tried >>> uninstalling libsasl2-devel but doing so had no

Re: "svn --version" halts in 1.7.2-2

Am 27.03.2010 00:15, schrieb David Rothenberger: > On 3/26/2010 2:07 PM, Corinna Vinschen wrote: >> On Mar 26 11:12, David Rothenberger wrote: >>> On 3/26/2010 2:32 AM, Corinna Vinschen wrote: On Mar 26 15:40, Nayuta Taga wrote: > "svn --version" hals in 1.7.2-2 on both Windows7 and XP. >>

Re: "svn --version" halts in 1.7.2-2

On 3/27/2010 12:31 PM, David Rothenberger wrote: > It seems all the dlnames are set to "cyg*.dll" already. Yep. > Do you have libsasl2-devel installed? Are you saying that it's working > fine for you with /usr/lib/sasl2/*.la files? Yes, and...it seems to work ok. I don't use svn very often; I ju

Re: "svn --version" halts in 1.7.2-2

Charles Wilson: > Hmm.  I remember having transient problems with svn and many of the > 1.7.0 snapshots, but they were intermittent and I had bigger fish to > fry.  I don't recall any issues with 1.7.1, nor am I having any trouble > with 1.7.2.  However, I would not be surprised if > > (a) the "pro

Re: "svn --version" halts in 1.7.2-2

On 3/27/2010 9:08 AM, Charles Wilson wrote: > On 3/27/2010 11:23 AM, David Rothenberger wrote: >> On 3/27/2010 7:47 AM, Charles Wilson wrote: >>> Obviously, something is going wrong there. What happens when the .la >>> file isn't found, is that libltdl falls back on cygwin's dlopen(), which >>> si

Re: "svn --version" halts in 1.7.2-2

On 3/27/2010 11:23 AM, David Rothenberger wrote: > On 3/27/2010 7:47 AM, Charles Wilson wrote: >> Obviously, something is going wrong there. What happens when the .la >> file isn't found, is that libltdl falls back on cygwin's dlopen(), which >> simply looks in the normal search path for the DLL -

Re: "svn --version" halts in 1.7.2-2

On 3/27/2010 7:47 AM, Charles Wilson wrote: > On 3/27/2010 12:10 AM, Eliot Moss wrote: >> On 3/26/2010 11:20 PM, David Rothenberger wrote: >>> I think the .la files are causing the problems. I believe they come from >>> libsasl2-devel. You said you removed that package, but maybe something >>> wen

Re: "svn --version" halts in 1.7.2-2

On 3/27/2010 12:10 AM, Eliot Moss wrote: > On 3/26/2010 11:20 PM, David Rothenberger wrote: >> I think the .la files are causing the problems. I believe they come from >> libsasl2-devel. You said you removed that package, but maybe something >> went wrong. > > Perhaps ... so I changed the directo

Re: "svn --version" halts in 1.7.2-2

On 3/26/2010 11:20 PM, David Rothenberger wrote: On 3/26/2010 8:03 PM, Eliot Moss wrote: I think the .la files are causing the problems. I believe they come from libsasl2-devel. You said you removed that package, but maybe something went wrong. Perhaps ... so I changed the directory name bac

Re: "svn --version" halts in 1.7.2-2

On 3/26/2010 8:03 PM, Eliot Moss wrote: >> Is there anything in /usr/lib/sasl2.disabled other than DLLs? > > Here a directory listing: > > $ ls -l /usr/lib/sasl2.disabled/ > total 324 > -rwxr-xr-x 1 Eliot root 15872 Oct 13 2004 cyganonymous-2.dll > -rwxr-xr-x 1 Eliot root 17920 Oct 13 2004 cygc

Re: "svn --version" halts in 1.7.2-2

Is there anything in /usr/lib/sasl2.disabled other than DLLs? Here a directory listing: $ ls -l /usr/lib/sasl2.disabled/ total 324 -rwxr-xr-x 1 Eliot root 15872 Oct 13 2004 cyganonymous-2.dll -rwxr-xr-x 1 Eliot root 17920 Oct 13 2004 cygcrammd5-2.dll -rwxr-xr-x 1 Eliot root 45056 Oct 13 2004

Re: "svn --version" halts in 1.7.2-2

On 3/26/2010 7:15 PM, Eliot Moss wrote: > On 3/26/2010 10:12 PM, David Rothenberger wrote: >> On 3/26/2010 5:57 PM, Eliot Moss wrote: >>> My Windows 7 system hands on svn --version also, but >>> produces no messages to /var/log/messages. I tried >>> uninstalling libsasl2-devel but doing so had no e

Re: "svn --version" halts in 1.7.2-2

On 3/26/2010 10:12 PM, David Rothenberger wrote: On 3/26/2010 5:57 PM, Eliot Moss wrote: My Windows 7 system hands on svn --version also, but produces no messages to /var/log/messages. I tried uninstalling libsasl2-devel but doing so had no effect. Regard -- Eliot Moss What happens if you ren

Re: "svn --version" halts in 1.7.2-2

On 3/26/2010 5:57 PM, Eliot Moss wrote: > My Windows 7 system hands on svn --version also, but > produces no messages to /var/log/messages. I tried > uninstalling libsasl2-devel but doing so had no effect. > > Regard -- Eliot Moss What happens if you rename /usr/lib/sasl2 to something else? % mv

Re: "svn --version" halts in 1.7.2-2

My Windows 7 system hands on svn --version also, but produces no messages to /var/log/messages. I tried uninstalling libsasl2-devel but doing so had no effect. Regard -- Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentati

Re: "svn --version" halts in 1.7.2-2

On 3/26/2010 2:07 PM, Corinna Vinschen wrote: > On Mar 26 11:12, David Rothenberger wrote: >> On 3/26/2010 2:32 AM, Corinna Vinschen wrote: >>> On Mar 26 15:40, Nayuta Taga wrote: "svn --version" hals in 1.7.2-2 on both Windows7 and XP. >> [snip] >>> >>> Works for me. BLODA? >> >> I'm able to

Re: "svn --version" halts in 1.7.2-2

On Mar 26 11:12, David Rothenberger wrote: > On 3/26/2010 2:32 AM, Corinna Vinschen wrote: > > On Mar 26 15:40, Nayuta Taga wrote: > >> "svn --version" hals in 1.7.2-2 on both Windows7 and XP. > [snip] > > > > Works for me. BLODA? > > I'm able to reproduce this on one of my three Windows XP mach

Re: "svn --version" halts in 1.7.2-2

On 3/26/2010 2:32 AM, Corinna Vinschen wrote: > On Mar 26 15:40, Nayuta Taga wrote: >> "svn --version" hals in 1.7.2-2 on both Windows7 and XP. [snip] > > Works for me. BLODA? I'm able to reproduce this on one of my three Windows XP machines. Ironically, the only one without a Symantec product i

Re: "svn --version" halts in 1.7.2-2

Am 26.03.2010 12:23, schrieb Dave Korn: > On 26/03/2010 10:12, Matthias Andree wrote: > >> Might of the additional libraries may have regressed? From the strace log, I >> suspect cygsasl2, which itself loads libraries, for instance >> /lib/sasl2/cygplain-2.dll and /lib/sasl2/cygsasldb-2.dll on my

Re: "svn --version" halts in 1.7.2-2

Am 26.03.2010 11:54, schrieb Corinna Vinschen: > On Mar 26 11:12, Matthias Andree wrote: >> Am 26.03.2010 10:32, schrieb Corinna Vinschen: >> > On Mar 26 15:40, Nayuta Taga wrote: >> >> Hi, >> >> >> >> "svn --version" hals in 1.7.2-2 on both Windows7 and XP. >> >> The log is following: >> >> [...]

Re: "svn --version" halts in 1.7.2-2

On 26/03/2010 10:12, Matthias Andree wrote: > Might of the additional libraries may have regressed? From the strace log, I > suspect cygsasl2, which itself loads libraries, for instance > /lib/sasl2/cygplain-2.dll and /lib/sasl2/cygsasldb-2.dll on my computer > (cygsasldb-2.dll is the last before

  1   2   >