> Alas this is the info for the JVM and does not work in this case. Most Java
> communication libraries ignore the JVM parameters for their own
> implementations. This is true of SVNKit, which reports that it relies
> completely on the configuration of the native svn client.
&g
as this is the info for the JVM and does not work in this case. Most
> Java communication libraries ignore the JVM parameters for their own
> implementations. This is true of SVNKit, which reports that it relies
> completely on the configuration of the native svn client.
>
> https:/
gt;
Alas this is the info for the JVM and does not work in this case. Most Java
communication libraries ignore the JVM parameters for their own
implementations. This is true of SVNKit, which reports that it relies
completely on the configuration of the native svn client.
https://svnkit.com/docume
also found out). I
> would assume Apache Subversion is using OS defaults when it comes to trying
> IPv4 or IPv6 first if a certain server has both addresses. When it comes to
> SVNKit I can't guess how Java handles IPv4 och IPv6 connections.
Is the IPv6 behaviour of the svn client (n
>>
>> The backstory is that I have some SVNKit code that is stubbornly insisting
>> on using IPv4 and failing. The SVNKit docs say it gets its config from the
>> native ~/.subversion directory, but I can find no mention of IPv6 and the
>> native svn client config. I am
is stubbornly insisting
> on using IPv4 and failing. The SVNKit docs say it gets its config from the
> native ~/.subversion directory, but I can find no mention of IPv6 and the
> native svn client config. I am specifically talking about an svn client
> accessing an IPv6 server over h
directory, but I can find no mention of IPv6 and the native svn
client config. I am specifically talking about an svn client accessing an IPv6
server over https, I am not using svnserve.
Regards,
Graham
—
> # available somehow. The easiest approach is to use the environment variable
> LD_LIBRARY_PATH, so that
> # users don't need to care to much. Therefore this wrapper calculates the
> necessary path on its own
> # and sets the environment variable accordingly.
> #
> # While use
iest approach is to use the environment variable
LD_LIBRARY_PATH, so that
# users don't need to care to much. Therefore this wrapper calculates the
necessary path on its own
# and sets the environment variable accordingly.
#
# While users are only interested in the SVN-client most likely, the wrapper
Hi all,
I have a customer using IPfire as firewall and wozuld like to maintain
some configs, firewall rules etc. using SVN. While that system
provides a package manager named Pakfire with GIT, SVN doesn't seem to
be supported anymore.
So, does anyone know of a compatible, statically linked client
reserved. Qualcomm Technologies Incorporated.
From: Thorsten
Sent: June 15, 2020 8:52 PM
To: Michael Back
Cc: users@subversion.apache.org
Subject: [EXT] Re: Bug: Svn client will no longer connect to old SVN server
Another stupid hackaround could be to setup a local
Another stupid hackaround could be to setup a local old proxy/man in the
middle https server that still accepts old tls connection, but also
provides newer protocols and switch your working copy to this server
instead.
But a much cleaner solution is to confront IT with the fact that they
nee
On Mon, Jun 15, 2020 at 5:05 AM Michael Back wrote:
> Hello Subversion folks,
>
> When I upgraded to the latest version of my Linux OS (Ubuntu 20.04) and
> installed Subversion 1.13.0 client, svn could no longer connect to our
> company's old subversion server via https.
> Doing a checkout result
On 15.06.2020 09:43, Michael Back wrote:
> Hello Subversion folks,
>
> When I upgraded to the latest version of my Linux OS (Ubuntu 20.04)
> and installed Subversion 1.13.0 client, svn could no longer connect to
> our company's old subversion server via https.
>
> $ svn --version
> svn, ver
Hello Subversion folks,
When I upgraded to the latest version of my Linux OS (Ubuntu 20.04) and
installed Subversion 1.13.0 client, svn could no longer connect to our
company's old subversion server via https.
$ svn --version
svn, version 1.13.0 (r1867053)
compiled Mar 24 2020, 12:33:36 on x
Branko ?ibej wrote:
>On 18.09.2019 03:48, William Muriithi wrote:
>>[...]
>> Would 1.9.7 clients qualify as a recent client?
>>
>For auto-props in the repository, yes, they were introduced in 1.8:
>[...]
on the other hand: the current version is 1.12.2
and the latest version in the 1.9 series
On 18.09.2019 03:48, William Muriithi wrote:
> Hi Brane,
>
> > The location hierarchy is explained in the book here:
> >
> > http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html
>
> But instead, use a recent client and put auto-props definitions
> into the
> reposit
Hi Brane,
> > The location hierarchy is explained in the book here:
> >
> > http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html
>
> But instead, use a recent client and put auto-props definitions into the
> repository instead.
>
>
> Would 1.9.7 clients qualify as a recent client?
Regard
On 17.09.2019 21:26, Mark Phippard wrote:
> On Tue, Sep 17, 2019 at 3:21 PM William Muriithi
> mailto:william.murii...@gmail.com>> wrote:
>
> Hello
>
> I want to make sure all the svn clients are using the same
> auto-props. I am aware this can be set on users home directory
> but
On Tue, Sep 17, 2019 at 3:21 PM William Muriithi
wrote:
> Hello
>
> I want to make sure all the svn clients are using the same auto-props. I
> am aware this can be set on users home directory but prefer to set it up
> globally in a host.
>
> Do svn clients look for a global file for configuratio
Hello
I want to make sure all the svn clients are using the same auto-props. I
am aware this can be set on users home directory but prefer to set it up
globally in a host.
Do svn clients look for a global file for configuration?
Regards,
William
On Mon, Dec 17, 2018 at 12:54 PM Cotrut, Michael <
michael.cot...@cbsa-asfc.gc.ca> wrote:
> Hi,
>
> It looks like ra-serf is missing from svn 1.11 client for windows
>
>
>
> Svn –version
>
> svn, version 1.11.0 (r1845130)
>
>compiled Nov 1 2018, 12:47:00 on x86/x86_64-microsoft-windows10.0.17
Hi,
It looks like ra-serf is missing from svn 1.11 client for windows
Svn -version
svn, version 1.11.0 (r1845130)
compiled Nov 1 2018, 12:47:00 on x86/x86_64-microsoft-windows10.0.17134
Copyright (C) 2018 The Apache Software Foundation.
This software consists of contributions made by many peo
Branko ~ibej [mailto:br...@apache.org] wrote:
> But if your console window [...]
The console is not the issue, or at least not the whole issue. Output
might be captured and viewed in an GUI application, or processed by a
script.
>> You can't even tell it to output utf-8, there's no such option.
Hello,
On 07.05.2018 14:27, Anders Munch wrote:
Fra: Mark Phippard [mailto:markp...@gmail.com]:
If you see a ? It means the font does not have a glyph for the character. Use a
Unicode font.
That would only help if svn would output some kind of unicode. It doesn't.
You can't even tell it to ou
On 07.05.2018 11:27, Anders Munch wrote:
> Fra: Mark Phippard [mailto:markp...@gmail.com]:
>> If you see a ? It means the font does not have a glyph for the character.
>> Use a Unicode font.
> That would only help if svn would output some kind of unicode.
Nonsense.
> It doesn't.
Subversion wil
Fra: Mark Phippard [mailto:markp...@gmail.com]:
> If you see a ? It means the font does not have a glyph for the character. Use
> a Unicode font.
That would only help if svn would output some kind of unicode. It doesn't.
You can't even tell it to output utf-8, there's no such option.
People talk
If you see a ? It means the font does not have a glyph for the character. Use a
Unicode font.
Sent from my iPhone
> On May 4, 2018, at 6:44 AM, Eugene M. Zheganin wrote:
>
> Hello,
>
>
> I'm trying to use the native windows client - svn.exe and it really looks
> like it corrupts or doesn't
Hello,
I'm trying to use the native windows client - svn.exe and it really
looks like it corrupts or doesn't reencodes properly UTF-8 symbols
froma repository (in svn history logs) to the native windows locale,
because in dates and content it shows question signs.
Is there any workaround t
On 10.02.2018 09:59, Thorsten Schöning wrote:
> Hi all,
>
> I'm using the PHP webapp WebSVN and ran into encoding problems with
> file names in my Linux environment when e.g. creating downloadable
> Zipr or Tars using WebSVN. I worked around those problems using a
> simple shell wrapper like the fo
Hi all,
I'm using the PHP webapp WebSVN and ran into encoding problems with
file names in my Linux environment when e.g. creating downloadable
Zipr or Tars using WebSVN. I worked around those problems using a
simple shell wrapper like the following:
> #!/bin/sh
>
> export LC_CTYPE=de_DE.UTF-8
> s
I have what I hope is a quick and simple question.
We have a requirement that we have some developers who do not have a laptop
nor a Citrix VDI and they need to be able to be able to make changes to
code within SVN. They have asked me if there are any applications which
would run in Tomcat/JBoss/
I am seeing same issue when sslv3 disabled sn checkout/info time out. Was there
any solution to previous problem?
Thanks
Murty
writes:
> Can you please confirm that the downgrading from v2 to v1 is away now?
Yes, that is v2.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Freitag, 9. Januar 2015 16:25
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: AW: Segmentation Fault with SVN Client
writes:
> Question: do you know when the patch for the header field name
> case-sensitiveness will be delivered? Is it planned for 1.8.12 SVN
> client?
It's approved for 1.8.12, see:
http://svn.apache.org/repos/asf/subversion/branches/1.8.x/STATUS
--
Philip Martin | Subver
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Freitag, 9. Januar 2015 12:19
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: Segmentation Fault with SVN Client related to
&
or
> this is that the HTTP specification states that the header-keys are
> case-insensitive (see
> f.i.
> http://stackoverflow.com/questions/5258977/are-http-headers-case-sensitive).
It's fixed on trunk and proposed for the next release.
> Maybe if this bug is fixed in the
;> Betreff: Re: AW: AW: Segmentation Fault with SVN Client related to serf
>>
>> writes:
>>
>>> You asked for the whole sequence of request, here is the whole tracing
>>> of our proxy: I hope this helps. But as already said: the svn client
>>> does not c
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Freitag, 9. Januar 2015 10:48
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: AW: AW: Segmentation Fault with SVN Client related to
>
writes:
> I have captured the http traffic, you will find it in the attachment
> crash_http_capture.pcap. The debugging output of the HttpProxy is in
> the attachment crash_http.txt, it differs from the output when using
> https. I had to switch from https to http for this. Please note that
> th
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Mittwoch, 7. Januar 2015 14:51
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: Segmentation Fault with SVN Client related to serf
>
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Donnerstag, 8. Januar 2015 14:34
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: AW: Segmentation Fault with SVN Client related to serf
Philip Martin writes:
> I can't reproduce this against a standard server.
I think I have worked it out. There was an error in my script: one of
the XML response lines was missing a '\n' and this originally caused the
client to report the HTTP response as too short, so I "fixed" it by
added a tr
Philip Martin writes:
> I've converted your trace into a Python script to implement a server
> that behaves like yours.
I may have reproduced the problem. If I remove the 'Connection: close'
headers and continue to force v1 I can get the client to crash using the
dummy server. I suppose that m
writes:
> The status line is not blocked. The debugging message means that we
> have got an header with a null key and with the status line as value:
> in this case the header is not added to the request sent back to the
> client. This seems to be common that some HTTP Implementations return
> su
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Mittwoch, 7. Januar 2015 14:51
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: AW: Segmentation Fault with SVN Client related to serf
>
writes:
> You asked for the whole sequence of request, here is the whole tracing
> of our proxy: I hope this helps. But as already said: the svn client
> does not crash always but 30% of the times we execute exactly the same
> ls command.
This is a bit confusing:
2015-01-06
> -Ursprüngliche Nachricht-
> Von: Stefan Sperling [mailto:s...@elego.de]
> Gesendet: Dienstag, 6. Januar 2015 15:59
> An: Philip Martin
> Cc: Viret Pierre, PF54; users@subversion.apache.org
> Betreff: Re: AW: Segmentation Fault with SVN Client related to serf
>
&
On Tue, Jan 06, 2015 at 02:01:52PM +, Philip Martin wrote:
> Typically the client will first send an OPTIONS request and get back a
> 401 or a 200. The client will then send further OPTIONS and PROPFIND
> requests. Can you identify which request and response is causing the
> crash? Also whic
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Dienstag, 6. Januar 2015 15:02
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: AW: Segmentation Fault with SVN Client related to serf
>
[...]
On Tue, Jan 06, 2015 at 02:01:52PM +, Philip Martin wrote:
> The crash is happening in the code that parses the status line,
> i.e. when handling something like
>
> HTTP/1.1 200 OK
>
> or
>
> HTTP/1.1 207 Multi-Status
>
> or
>
> HTTP/1.1 401 Authorization Required
> Breakpoint 1,
server used as
> subversion server
> - the apache server uses a proprietary module for authentication using
> a security token placed in the http header.
> - there is no authentication between the svn client and the local http-proxy
> - the svn client is not aware that it connects through
> -Ursprüngliche Nachricht-
> Von: Philip Martin [mailto:philip.mar...@wandisco.com]
> Gesendet: Dienstag, 6. Januar 2015 12:49
> An: Viret Pierre, PF54
> Cc: users@subversion.apache.org
> Betreff: Re: Segmentation Fault with SVN Client related to serf
>
> wri
writes:
> viretp@mwbox:~$ svn ls https://127.0.0.1:7771/svn/t_sponis_testrepo
> Segmentation fault
>
> In /var/log/syslog:
> Jan 5 14:31:23 mwbox kernel: [14750.072747] svn[21822]: segfault at
> 7f3733f39000 ip 7f37328ae3cf sp 7fff9e3df468 error 7 in
> libc-2.13.so[7f373278a000+182000]
Hello
We have following problem with the SVN native clients in our environment: the
client crashes with a memory access violation error while executing an "ls"
command. We have reproduced the error on debian with SVN 1.8.10 and on Windows
with the latest SVN 1.8.11. With older versi
Which serf version you are using for svn client ?
regards
Mohsin
--
View this message in context:
http://subversion.1072662.n5.nabble.com/svn-client-stopped-working-after-server-disabled-SSLv3-tp190707p190708.html
Sent from the Subversion Users mailing list archive at Nabble.com.
Hello!
We are disabling SSLv3 on our servers to address the POODLE bug in the protocol.
Unfortunately, doing so breaks svn-clients on some of our systems -- most
notably, the RHEL5 boxes:
svn: OPTIONS of 'https://svn.example.net/svn/foo': SSL negotiation failed:
Secure connection truncat
Overview of problem:
Using svn client 1.8.10 on Mac OSX 10.9.4, downloaded from wandisco.
When trying to sync trunk to a branch with the command: svn merge ^/trunk
I get the following error:
svn merge ^/trunk
svn: E195016: Reintegrate can only be used if revisions 3 through 6 were
previously
On 4/9/14, 7:56 AM, msk...@ansuz.sooke.bc.ca wrote:
> My main question is: how do I get the Subversion command-line client to
> read a CRL? The ssl-authority-files configuration setting lets me specify
> my CA's root certificate in a file; is there a similar setting for the
> CRL? I would prefer
> -Original Message-
> From: Ben Reser [mailto:b...@reser.org]
> Sent: woensdag 9 april 2014 21:28
> To: msk...@ansuz.sooke.bc.ca; users@subversion.apache.org
> Subject: Re: SVN client SSL CRL configuration
>
> On 4/9/14, 8:56 AM, msk...@ansuz.sooke.bc.ca wrote:
&
On 4/9/14, 8:56 AM, msk...@ansuz.sooke.bc.ca wrote:
> I'm not subscribed to the list and would appreciate a cc: on any replies.
>
> I run a Subversion server accessible through Apache HTTPS, and several
> clients that connect to it, all under Linux, and I run my own CA
> (certificate authority) to
I'm not subscribed to the list and would appreciate a cc: on any replies.
I run a Subversion server accessible through Apache HTTPS, and several
clients that connect to it, all under Linux, and I run my own CA
(certificate authority) to issue SSL certificates to all parties. When I
set it up, I m
First, thanks for your answer, and sorry my late answer
On Mon, Feb 03, 2014 at 03:05:28PM -0800, Ben Reser wrote:
> On 2/3/14, 2:26 PM, Marc MERLIN wrote:
> > On my personal system, I got a new svn and as prompted by "your repo is
> > too old", upgraded it to the new format (svn 1.7.13).
>
> You
On 2/3/14, 2:26 PM, Marc MERLIN wrote:
> On my personal system, I got a new svn and as prompted by "your repo is
> too old", upgraded it to the new format (svn 1.7.13).
You mean working copy, there is no such message about repositories. We support
repositories all the way back to 1.0.
> And now
Howdy,
On my personal system, I got a new svn and as prompted by "your repo is
too old", upgraded it to the new format (svn 1.7.13).
And now I'm very hosed.
legolas:/var/local/scr# svn update
svn: E155037: Previous operation has not finished; run 'cleanup' if it was
interrupted
legolas:/var/loc
On 29.01.2014 09:10, Roman Kellner wrote:
> Hi
>
> We are using a MSSCCI to SVN client (PushOk) which in the version 1.7.13 and
> with our project does strange things.
> When opening our IDE SccProjectOpen() is called on the MSSCCI interface.
>
> I do not exactly know wh
Hi
We are using a MSSCCI to SVN client (PushOk) which in the version 1.7.13 and
with our project does strange things.
When opening our IDE SccProjectOpen() is called on the MSSCCI interface.
I do not exactly know what is done on the SVN level, but with the
SccProjectOpen() call, outdated local
...@subversion.apache.org
Cc: users@subversion.apache.org
Subject: SVN client 1.8.x: unable to checkout public repositories when
behind a web proxy
Hello all,
I have come across the following situation:
- With SVN client 1.8.x (specifically Tortoise 1.8.4), I'm not able
to checkout p
Hello all,
I have come across the following situation:
- With SVN client 1.8.x (specifically Tortoise 1.8.4), I'm not able to
checkout public repositories when behind a (company) web proxy. You can try as
an example to checkout from http://net-orcades-spring.googlecode.com/svn/
I replied yesterday, but my post seems to have disappeared.
I figured it out, and the key was your reproduction and my realisation I
wasn't seeing a FIN from my server. It turns out that in every case the last
392598 71.906863000 10.222.3.88 10.14.11.50 HTTP 1434 Continuation or
non-HTTP traffic
Stuart MacDonald writes:
> svn: E175002: REPORT of '/svn/repos/deckard-65x/!svn/me': Could not read
> response body: connection was closed by server (http://foundry51.qnx.com)
I can provoke this on my local LAN by setting the Apache timeout on the
server to a low value such as 5 seconds. Then I
Here's this morning's failure. For testing, I've set http-timeout=67. I am
trying to see if the zero window is a coincidence or not.
The debug output:
Reading 8192 bytes of response body.
Got 8192 bytes.
XML: Parsing 8192 bytes.
XML: char-data (235) returns 0
XML: xmlParseChunk returned 0
Reading
I don't have access to the server log, but you can see from the wireshark
capture that the *client* closed the connection (look for the RST packet),
not the server. The error of "socket closed" is consistent with that.
I suspect that there's an issue handling the "http-timeout" timer; it gets
trig
Philip Martin writes:
> That message comes from ne_request.c and the -3 is NE_SOCK_CLOSED
> defined in ne_socket.h:
>
> #define NE_SOCK_CLOSED (-3)
> /* Connection was reset (e.g. server crashed) */
/* Socket was closed */
#define NE_SOCK_CLOSED (-3)
The comment associated with the constant is
stuartm.cod...@gmail.com writes:
> I have another failure, with some debug info, and some updates.
>
> We're switching to a different system for this particular repository, so I
> may or may not be able to continue debug efforts. :-(
>
> Since there's no debug info available for the svn 1.8 clien
On Mon, Dec 23, 2013 at 4:47 PM, Stuart MacDonald
wrote:
> I took some time last Fri to see what was 180 seconds prior to the FIN
> packet in the trace (this is the 1.7.14 failure):
> 289223259.41852100010.222.3.8810.14.10.32HTTP1434
> Continuation or non-HTTP traffic
> 289224
On Mon, Dec 23, 2013 at 3:51 PM, Lieven Govaerts wrote:
> to be clear, you've tested:
> - svn 1.7.13 with ra_neon, svn 1.7.14 with ra_neon and 1.8.5 with ra_serf.
> - to an svn 1.7.7 server
> - over http, with nginx 1.0.5. as intermediate proxy
> - running 'svn up'
> - on an Ubuntu guest (version
Hi Stu,
On Mon, Dec 23, 2013 at 6:11 PM, wrote:
> On Tuesday, December 17, 2013 10:32:34 AM UTC-5, Branko Čibej wrote:
>>
>> On 17.12.2013 16:19, Stuart MacDonald wrote:
>> > The Wireshark trace shows clearly and conclusively this is a bug in
>> > the client. The client drops the connection by s
On Tuesday, December 17, 2013 10:32:34 AM UTC-5, Branko Čibej wrote:
>
> On 17.12.2013 16:19, Stuart MacDonald wrote:
> > The Wireshark trace shows clearly and conclusively this is a bug in
> > the client. The client drops the connection by sending a FIN packet
> > unexpectedly.
>
> It could be
On Monday, December 16, 2013 1:45:11 PM UTC-5, Branko Čibej wrote:
>
> So your server is using an nginx proxy, and your 1.7 client doesn't work
> with it. The thing to do is to try to reproduce this with 1.8, and if it's
> reproducible, it's still most likely a proxy bug (nginx 1.0.5 is rather
On Mon, Dec 16, 2013 at 12:45 PM, Mark Phippard wrote:
> On Mon, Dec 16, 2013 at 12:31 PM, Stuart MacDonald <
> stuartm.cod...@gmail.com> wrote:
>
>> If someone can point me at a Ubuntu-compatible package, I'm more than
>> happy to upgrade. Last time I looked (within the last two months) I was
>>
On 17.12.2013 16:19, Stuart MacDonald wrote:
> On Monday, December 16, 2013 1:45:11 PM UTC-5, Branko Čibej wrote:
>
> So your server is using an nginx proxy, and your 1.7 client
> doesn't work with it. The thing to do is to try to reproduce this
> with 1.8, and if it's reproducible, it'
Thanks, I'll pass it along. It mentions that commit access is required to
exploit this though, so I think IT will probably ignore this if they
haven't already patched it.
...Stu
On Mon, Dec 16, 2013 at 2:20 PM, Ben Reser wrote:
> On 12/16/13 11:08 AM, Stuart MacDonald wrote:
> > svn is 1.7.7
On 12/16/13 11:08 AM, Stuart MacDonald wrote:
> svn is 1.7.7 (we are not planning to upgrade for some time)
This doesn't help with your issue but if you need ammo to convince IT to
upgrade:
https://subversion.apache.org/security/CVE-2013-4131-advisory.txt
If it's a distribution package it might
IT says we have:
nginx 1.05 with plans to move to 1.3.9
svn is 1.7.7 (we are not planning to upgrade for some time)
...Stu
On Mon, Dec 16, 2013 at 12:45 PM, Stuart MacDonald wrote:
> The link I provided is *exactly* what I'm seeing, so I didn't see the need
> to repeat that post. I'm in a VM,
On 16.12.2013 18:45, Stuart MacDonald wrote:
> The link I provided is *exactly* what I'm seeing, so I didn't see the
> need to repeat that post. I'm in a VM, the client drops the connection
> with an erroneous [FIN, ACK], just after the TCP window opens up again.
>
> Hm, one detail I can provide no
On Mon, Dec 16, 2013 at 12:31 PM, Stuart MacDonald wrote:
> If someone can point me at a Ubuntu-compatible package, I'm more than
> happy to upgrade. Last time I looked (within the last two months) I was
> unable to find anything later than what I'm running. I'd rather not spend
> the time compil
The link I provided is *exactly* what I'm seeing, so I didn't see the need
to repeat that post. I'm in a VM, the client drops the connection with an
erroneous [FIN, ACK], just after the TCP window opens up again.
Hm, one detail I can provide now that's not in that post:
U directory/file1
U direc
Guten Tag Stuart MacDonald,
am Montag, 16. Dezember 2013 um 18:31 schrieben Sie:
> If someone can point me at a Ubuntu-compatible package[...]
We use the package form Wandisco on our LTS 12.04.
http://subversion.apache.org/packages.html#ubuntu
Mit freundlichen Grüßen,
Thorsten Schöning
--
Th
If someone can point me at a Ubuntu-compatible package, I'm more than happy
to upgrade. Last time I looked (within the last two months) I was unable to
find anything later than what I'm running. I'd rather not spend the time
compiling from source if I can avoid it.
Please elucidate "capture traces
On Mon Dec 16 07:56:32 2013, Stuart MacDonald wrote:
>
> I am seeing exactly this
> issue: https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc
> but do not find a bug report for it in the database. The linked bug is for
> something similar but unrelated. Can I file this?
>
> ...Stu
On Mon, Dec 16, 2013 at 10:56 AM, Stuart MacDonald wrote:
>
> I am seeing exactly this issue:
> https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc but
> do not find a bug report for it in the database. The linked bug is for
> something similar but unrelated. Can I file this?
>
>
I am seeing exactly this issue:
https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc but do
not find a bug report for it in the database. The linked bug is for
something similar but unrelated. Can I file this?
...Stu
stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --vers
(Ubuntu)
Server built: Jul 12 2013 13:37:10
People have started updating their clients to 1.8. While on svn:// they
have no issues, with web_dav, the situation is different.
Any update or checkout on http:// leads to a 408 error from SVN client
(Timeout request).
I went down to the Apache2 log
On 08.08.2013 13:04, Nico Kadel-Garcia wrote:
On Thu, Aug 8, 2013 at 5:32 AM, Ivan Zhakov wrote:
On Thu, Aug 8, 2013 at 12:36 PM, Stefan Sperling wrote:
On Thu, Aug 08, 2013 at 10:18:42AM +0200, Elias Gerber wrote:
Since svn 1.8.x we experience the following:
Clients that are part of the dom
On Thu, Aug 8, 2013 at 5:32 AM, Ivan Zhakov wrote:
> On Thu, Aug 8, 2013 at 12:36 PM, Stefan Sperling wrote:
>> On Thu, Aug 08, 2013 at 10:18:42AM +0200, Elias Gerber wrote:
>>> Since svn 1.8.x we experience the following:
>>> Clients that are part of the domain can log in without any problems.
>
On Thu, Aug 8, 2013 at 12:36 PM, Stefan Sperling wrote:
> On Thu, Aug 08, 2013 at 10:18:42AM +0200, Elias Gerber wrote:
>> Since svn 1.8.x we experience the following:
>> Clients that are part of the domain can log in without any problems.
>> Clients that are not part of the domain try to log-in f
On 08.08.2013 10:36, Stefan Sperling wrote:
On Thu, Aug 08, 2013 at 10:18:42AM +0200, Elias Gerber wrote:
Since svn 1.8.x we experience the following:
Clients that are part of the domain can log in without any problems.
Clients that are not part of the domain try to log-in forever using
the loca
On Thu, Aug 08, 2013 at 10:18:42AM +0200, Elias Gerber wrote:
> Since svn 1.8.x we experience the following:
> Clients that are part of the domain can log in without any problems.
> Clients that are not part of the domain try to log-in forever using
> the local account. The server rejects those cre
1 - 100 of 177 matches
Mail list logo
