Change SVNParentPath

[Juan Jesús Cremades Monserrat]

Hi!

I continue building a svn server with remote datasource. I want to look up
an idea: If I mount a remote hard disk across SAMBA and I change the
SVNParentPath to this device, will it be works fine? Thanks!!!

RE: How to use GNOME keyring with Subversion

[Giulio Troccoli]

>


Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851VAT Reg No 778499447

-Original Message-


> From: Mark Phippard [mailto:markp...@gmail.com]
> Sent: 15 January 2010 16:37
> To: Giulio Troccoli
> Cc: users@subversion.apache.org
> Subject: Re: How to use GNOME keyring with Subversion
>
> On Fri, Jan 15, 2010 at 11:33 AM, Giulio Troccoli
>  wrote:
> > Although I have been using Subversion since 1.2, so for
> quite a while, I'm very new to GNOME keyring. I would like to
> set it up but I don't seem able to do that.
> >
> > I have, for testing, created a VM with CentOS 5.4. Then I
> have built Subversion 1.6.6 from source with the
> --with-gnome-keyring option.
> >
> > The gnome-keyring-daemon is running (does it need any
> parameters?) and the keyring manager show an unlocked session
> called "session".
> >
> > I have change the config file to use gnome-keyring and the
> servers files with store-passwords = yes and
> store-plaintext-passwords = no.
> >
> > Still, when I update an existing wc I am asked for the
> Subversion password every time.
> >
> > As I said I am totally new to keyring and stuff like that, so if
> > anyone has successfully set it up please help me :-)
> >
> > Of course, if you need more information just ask
>
> The CollabNet RPM has gnome-keyring support and installs into
> a private location (/opt/CollabNet_Subversion) so it will not
> mess up your other build or install.  I'd suggest you try it
> to rule out problems with your build.

I'll try that and report back.

> I assumed you made sure you were using your build and not the
> version that comes with CentOS.

Of course :-)

RE: HELP! Can't commit anymore: svn: PROPFIND ... Service Unavailable

[Ullrich.Jans]

Peter Koellner wrote:
> Hi!
> 
> I am working on a slightly outdated OpenSuSE system that has
> subversion 1.4.4 installed. Since an hour or so, I can't do any
> commits anymore. Everything else seems to work, but no commits.
> 
> I even checked out a fresh working copy with
> 
> svn co http://localhost/svn/meinefc/branches/RELEASE-BETA test
> 
> which worked, but all I get on commit is:
> 
> Hinzufügen meinefc/test.txt
> svn: Übertragen fehlgeschlagen (Details folgen):
> svn: PROPFIND Anfrage fehlgeschlagen auf
> »/svn/meinefc/branches/RELEASE-BETA/sites/all/modules/meinefc/
> test.txt« svn: PROPFIND von
> »/svn/meinefc/branches/RELEASE-BETA/sites/all/modules/meinefc/
> test.txt«: 503 Service unavailable (http://localhost) 
> svn: Ihre Logmeldung wurde in einer Temporärdatei abgelegt:
> svn:'/home/koellpe/test/sites/all/modules/svn-commit.tmp'
> 
> 
> Everything else works. checkout, update, access but no commit!
> I have restarted apache, and I don't see any error
> messages. Everything worked until an hour ago, there were no
> configuration changes. 
> 
> There are no log messages, no further error messages, no verbose
> messages, no debug messages. 
> 
> Does anybody have any idea how to solve this? This is extremely
> urgent, since I am in the middle of a very complicated product
> update and had to put the web site offline until finishing this update
> operation

Did you check your system, e.g. if there is enough disk space, etc.?

(Sorry for the late answer - I guess it's not a subversion problem, so nobody 
felt the need to answer, as well as reading this ML is low-prio... ;-))

Ulli

-- 
Ullrich Jans, Application Support, IM
Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com 
Fax: +49 9131 7701-6333, www.elektrobit.com

Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany
Managing Directors: Otto Fößel, Jarkko Sairanen
Register Court Fürth HRB 4886 



Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

Re: Change SVNParentPath

[Ulrich Eckhardt]

On Monday 18 January 2010, Juan Jesús Cremades Monserrat wrote:
> I continue building a svn server with remote datasource. I want to look
> up an idea: If I mount a remote hard disk across SAMBA and I change the
> SVNParentPath to this device, will it be works fine? Thanks!!!

I think the FAQ contains a section dealing with repositories and working 
copies on remote filesystems.

Uli


-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

RE: sync bug -> corrupted proxy repo

[Jon Foster]

Hi,

> I am assuming that if the commits must start at least one
> second apart - then the sync from the post-commit hook
> would not be able to reach a race condition.
> Is this a reasonable assumption?

No, the bug is worse than that.  Suppose there are 3 commits:

- At time 12:00:00, a commit starts sync process #1.  The sync
  takes 6 seconds.
- At time 12:00:02, a commit starts sync process #2.  This blocks
  due to sync process #1's lock.
- At time 12:00:04, a commit starts sync process #3.  This blocks
  due to sync process #1's lock.
- At time 12:00:06, sync process #1 finishes.  Sync processes #2 and
  #3 both try to take the lock; due to the bug they may _both_
  succeed in taking the lock.  Chaos ensues.

I suggest you use the "flock(1)" tool. [1].  This is installed as
a standard part of Debian (it's in the util-linux package).
Something like this, in your post-commit hook:

--- cut here - start ---
#!/bin/sh

/usr/bin/flock --wait 1200 \
-x /var/lock/svn_sync_lock \
/usr/local/bin/svnsync sync --non-interactive \
http://mirrorserver.example.com/svn &
--- cut here - end ---

You will need to make the /var/lock/svn_sync_lock file and ensure
it's writable by the user your post-commit hook is running as.

"flock" is a mature, tested piece of code to handle locking.
It will ensure that only one copy of svnsync is running at a
time.  That way, the race condition in svnsync is avoided.

Kind regards,

Jon

[1] http://www.google.co.uk/search?q=man+flock%281%29

-Original Message-
From: Andersen, Krista [mailto:krista.ander...@itg.com] 
Sent: 15 January 2010 22:29
To: Jon Foster; users@subversion.apache.org
Cc: ssi-svn_admin
Subject: RE: sync bug -> corrupted proxy repo

Thank you Jon, for your explanation and workaround.

Are there any "best practices" that we can advise our dev groups to
follow to avoid this problem?

Otherwise, your suggestions seem to indicate I would have to run the
sync on a cronjob and not with the hook script.  That is something we
would like to avoid.  So I have added a start time comparison and sleep
in a start-commit hook instead.  Do you see any reason why this would
cause other problems?

I am assuming that if the commits must start at least one second apart -
then the sync from the post-commit hook would not be able to reach a
race condition.  Is this a reasonable assumption?

#!/usr/bin/sh

# START-COMMIT HOOK
# kanderse Jan 13, 2010

# The start-commit hook is invoked before a Subversion txn is created
# in the process of doing a commit.

# This script checks the start time and compares with the start time
# of the previous commit.  It will cause a commit to wait one second if
# the last commit was started less than one second earlier.

# The purpose of this wait is to prevent known issue 3546 [1][2].
# a race condition involving multiple sync processes running at
# the same time that result in a corrupted proxy.

REPOS="$1"
USER="$2"

DATE1=`cat /$REPOS/hooks/start-time.txt` # previous start time
DATE2=`/usr/local/bin/date +%s` # record current start time
echo $DATE2 > /$REPOS/hooks/start-time.txt
# echo $DATE2 $DATE1 `expr $DATE2 - $DATE1`

if [ `expr $DATE2 - $DATE1` -lt 1 ]
then sleep 1 # to prevent sync race that results in sync duplication and
corrupted proxy
fi
# All checks passed, so allow the commit.
exit 0

Krista Andersen

Global Development Infrastructure
Investment Technology Group, Inc.
400 Corporate Pointe, 8th Floor
Culver City, CA 90230
Direct: 213.270.7570



-Original Message-
From: Jon Foster [mailto:jon.fos...@cabot.co.uk]
Sent: Wednesday, January 13, 2010 5:13 AM
To: Andersen, Krista; users@subversion.apache.org
Cc: ssi-svn_admin
Subject: RE: sync bug -> corrupted proxy repo

Hi,

Andersen, Krista [mailto:krista.ander...@itg.com] wrote:
> Twice I have seen one of my proxy repositories become corrupted due
> to an apparent bug in the svnsync sync process.  Has anyone else
> seen this type of behavior from Subversion?

This is probably caused by issue 3546 [1][2].  This is a race
condition - if you have several sync processes running at the same
time then the mirror can get corrupted.  You had three commits which
were 1 second apart, so your hook script started 3 copies of svnsync
within 2 seconds.  I think this is the first practical report of this
bug; previous discussion was theoretical.

> Here is a comparison the output of the svn log -v for the offending
> revisions (324,325) on both the corrupted and non-corrupted proxy
> repo.

It looks like rev 323 got mirrored twice (as mirror revs 323 and 324),
then rev 324 was mirrored (as mirror rev 325).

> I am a bit concerned about the stability of Subversion since this
> is the second time in two months that I have had to fix this issue.
> Is there a patch or something to prevent this in the future?

Suggested workaround: Change your hook scripts to use the lockf or
lockfile tools[3] to ensure that only one instance of svnsync runs
at once.

Kind regards,

Jon

Re: Errors while checking out large directory

[Andy Levy]

On Fri, Jan 15, 2010 at 15:16, Mark Phippard  wrote:
> On Fri, Jan 15, 2010 at 3:08 PM, Andy Levy  wrote:
>> I've found several references to this problem via Google & the list
>> archives, but never any answers.
>>
>> When checking out from *some* clients (one in particular), I get the
>> following errors in my Apache error log on a regular basis:
>>
>> [Fri Jan 15 12:33:57 2010] [error] [client IP] Provider encountered an
>> error while streaming a REPORT response.  [500, #0]
>> [Fri Jan 15 12:33:57 2010] [error] [client IP] A failure occurred
>> while driving the update report editor  [500, #190004]
>>
>> My SVN server is CollabNet's distribution of 1.5.2 running on Windows
>> 2003 with the default configuration of Apache that's included.
>
> This is usually an issue with the client where it is not responding
> fast enough and the server thinks the connection has been dropped.
> For example, the client can spend so long writing the working copy
> that the server thinks it dropped.
>
> http://subversion.tigris.org/faq.html#secure-connection-truncated
>
> There is a timeout in the httpd.conf you can set to make the server
> wait longer.  I do not recall what it is off the top of my head.
>
> I think if you changed the client to use Serf instead of Neon you
> would also avoid this problem.  Neon does this all as one giant HTTP
> request, where as Serf breaks it up into lots of smaller GET requests.
>  So I do not think Serf would likely timeout.
>
> You should be able to just edit the %AppData%\Subversion\servers file
> on the client to tell it to use Serf over Neon (assuming your binaries
> support it).
>
> [global]
> http-library = serf
>
> If Anthill uses SVNKit then I am not sure what you can do other than
> increase the timeout on the server.

I'll experiment some with the client config this morning, thanks.

I'm not presently capturing User-Agent in my httpd logs - if I was,
would that help me identify whether a client is using Serf or Neon?

Re: Errors while checking out large directory

[Mark Phippard]

On Mon, Jan 18, 2010 at 8:44 AM, Andy Levy  wrote:
>> You should be able to just edit the %AppData%\Subversion\servers file
>> on the client to tell it to use Serf over Neon (assuming your binaries
>> support it).
>>
>> [global]
>> http-library = serf
>>
>> If Anthill uses SVNKit then I am not sure what you can do other than
>> increase the timeout on the server.
>
> I'll experiment some with the client config this morning, thanks.
>
> I'm not presently capturing User-Agent in my httpd logs - if I was,
> would that help me identify whether a client is using Serf or Neon?

Neon is the default so it is pretty unlikely someone would be using
Serf.  I do not think the User-Agent identifies which library is used.
 It does however, tell you if SVNKit is being used.

The request pattern in the logs between Serf and Neon is very
different and that would be the main giveaway.  An update with Neon is
mostly a single large REPORT request.  With Serf it is a small REPORT
request followed by a GET for each resource you need to update.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Errors while checking out large directory

[Andy Levy]

On Mon, Jan 18, 2010 at 08:55, Mark Phippard  wrote:
> On Mon, Jan 18, 2010 at 8:44 AM, Andy Levy  wrote:
>>> You should be able to just edit the %AppData%\Subversion\servers file
>>> on the client to tell it to use Serf over Neon (assuming your binaries
>>> support it).
>>>
>>> [global]
>>> http-library = serf
>>>
>>> If Anthill uses SVNKit then I am not sure what you can do other than
>>> increase the timeout on the server.
>>
>> I'll experiment some with the client config this morning, thanks.
>>
>> I'm not presently capturing User-Agent in my httpd logs - if I was,
>> would that help me identify whether a client is using Serf or Neon?
>
> Neon is the default so it is pretty unlikely someone would be using
> Serf.  I do not think the User-Agent identifies which library is used.
>  It does however, tell you if SVNKit is being used.
>
> The request pattern in the logs between Serf and Neon is very
> different and that would be the main giveaway.  An update with Neon is
> mostly a single large REPORT request.  With Serf it is a small REPORT
> request followed by a GET for each resource you need to update.

Looks like Anthill can't use serf, my logs show the same pattern
between yesterday & today. I know that the client config is being
picked up from the right place because use-commit-times is being
honored.

Here's what I'm seeing:

172.30.5.40 - - [17/Jan/2010:20:56:02 -0500] "PROPFIND PATH HTTP/1.1" 207 736
172.30.5.40 - - [17/Jan/2010:20:56:02 -0500] "REPORT
/Repos/Code/!svn/vcc/default HTTP/1.1" 200 883378845

883MB response being streamed back to the client, I guess the default
5 minute timeout isn't quite enough sometimes.

The way I have things configured, Anthill is checking out a copy of
the project while Tomcat is finishing the deployment of the previous
build into its temp/working directory. Maybe these overlapped
I/O-intensive tasks are slowing each other down? Often the first build
succeeds, and subsequent ones fail. I'll have to try doing them
independently later today.

RE: HELP! Can't commit anymore: svn: PROPFIND ... Service Unavailable

[Peter Koellner]

On Mon, 18 Jan 2010, ullrich.j...@elektrobit.com wrote:


Did you check your system, e.g. if there is enough disk space, etc.?


Yes. Everything fine, nothing suspicious.


(Sorry for the late answer - I guess it's not a subversion problem, so nobody 
felt the need to answer, as well as reading this ML is low-prio... ;-))


Well, I kind of solved the problem. It stopped working for all checked
out copies of that user, even new ones. So I logged in as a different user,
copied the changed files into a different (existing) work copy, checked
in from there, switched user again, did an update and after that
everything worked again. I don't know why. Which is very bad.
The first law of version control is: It's either reliable or
worthless. Searching the web for the problem did not give good
answers, except that it occasionally happened to different people
under different circumstances, but in most cases without any solutions
given. Unfortunately I don't know how to reproduce the error, since
I did nothing unusual there. The only hint of an idea would be that it
started when I added a filename which I already added in a different
branch a week ago, but I don't know if that has anything to do with it.
I hope this does not happen again after updating the system to a more
recent version as soon as possible...

--
peter koellner 

Re: HELP! Can't commit anymore: svn: PROPFIND ... Service Unavailable

[David Weintraub]

Okay, this is late. I see you're using Apache as your transaction
engine, you're using SUSE, and you're using an old version of
Subversion. Sounds frightfully familiar. We use to have a similar
setup.

Are your repositories read/writable by the HTTP process? On SUSE,
these have to be read/writable by user 'wwwrun'. All files under your
repository directory need to be owned and read/writable by "wwwrun".

We had similar issues where files and directories were suddenly owned
by "root". We never traced down the issue, but we moved over to Redhat
and updated Subversion server to the most recent copy.

On Tue, Jan 12, 2010 at 7:34 PM, Peter Koellner  wrote:
> Hi!
>
> I am working on a slightly outdated OpenSuSE system that has
> subversion 1.4.4 installed.
> Since an hour or so, I can't do any commits anymore. Everything else
> seems to work, but no commits.
>
> I even checked out a fresh working copy with
>
> svn co http://localhost/svn/meinefc/branches/RELEASE-BETA test
>
> which worked, but all I get on commit is:
>
> Hinzufügen     meinefc/test.txt
> svn: Übertragen fehlgeschlagen (Details folgen):
> svn: PROPFIND Anfrage fehlgeschlagen auf
> »/svn/meinefc/branches/RELEASE-BETA/sites/all/modules/meinefc/test.txt«
> svn: PROPFIND von
> »/svn/meinefc/branches/RELEASE-BETA/sites/all/modules/meinefc/test.txt«:
> 503 Service unavailable (http://localhost)
> svn: Ihre Logmeldung wurde in einer Temporärdatei abgelegt:
> svn:    '/home/koellpe/test/sites/all/modules/svn-commit.tmp'
>
>
> Everything else works. checkout, update, access but no commit!
> I have restarted apache, and I don't see any error
> messages. Everything worked until an hour ago, there were no
> configuration changes.
>
> There are no log messages, no further error messages, no verbose
> messages, no debug messages.
>
> Does anybody have any idea how to solve this? This is extremely
> urgent, since I am in the middle of a very complicated product
> update and had to put the web site offline until finishing this update
> operation
>
>
> --
> peter koellner 
>



-- 
David Weintraub
qazw...@gmail.com

Python & RA

[Daniel Eggert]

I've been trying to use python to use Subversion’s Remote Access library, but 
it crashes.



#!/usr/bin/python

import os
import svn
import svn.ra
import svn.client
import svn.core

svn.ra.initialize()


class Callbacks(svn.ra.Callbacks):
def __init__(self):
self.auth_baton = svn.core.svn_auth_open([
svn.client.get_simple_provider(),
svn.client.get_username_provider(),
])
svn.core.svn_auth_set_parameter(self.auth_baton,

svn.core.SVN_AUTH_PARAM_DEFAULT_USERNAME,
"eggert")
svn.core.svn_auth_set_parameter(self.auth_baton,

svn.core.SVN_AUTH_PARAM_DEFAULT_PASSWORD,
"aaa")
def open_tmp_file(self, pool):
path = '/tmp/'
(fd, fn) = tempfile.mkstemp(dir=path)
os.close(fd)
return fn
def cancel_func(self):
if False:
return svn.core.SVN_ERR_CANCELLED
return 0

c = Callbacks()
svn.ra.open2("http:/svn.example.com/svn", c, {})



My backtace looks like this:

0   ??? 0x0001005390f0 0 + 4300443888
1   libapr-1.0.dylib0x00010110cde5 apr_hash_get + 11
2   libsvn_ra-1.0.dylib 0x0001001f4d8f svn_ra_open3 + 186
3   libsvn_ra-1.0.dylib 0x0001001f3572 svn_ra_open2 + 28
4   _ra.so  0x000100735b61 0x10073 + 23393
5   org.python.python   0x0001b173 PyObject_Call + 112
6   org.python.python   0x000100084b6f 
PyEval_CallObjectWithKeywords + 175
7   org.python.python   0x000100083a9e _PyBuiltin_Init + 14071
8   org.python.python   0x0001000891df PyEval_EvalFrameEx + 15001
9   org.python.python   0x00010008accf PyEval_EvalCodeEx + 1803
10  org.python.python   0x0001000893aa PyEval_EvalFrameEx + 15460
11  org.python.python   0x00010008accf PyEval_EvalCodeEx + 1803
12  org.python.python   0x00010008ad62 PyEval_EvalCode + 54
13  org.python.python   0x0001000a265a Py_CompileString + 78
14  org.python.python   0x0001000a2723 PyRun_FileExFlags + 150
15  org.python.python   0x0001000a423d PyRun_SimpleFileExFlags + 704
16  org.python.python   0x0001000b0286 Py_Main + 2718
17  org.python.python.app   0x00010e6c start + 52


What am I doing wrong?

/Daniel

Re: Errors while checking out large directory

[Andy Levy]

On Mon, Jan 18, 2010 at 09:27, Andy Levy  wrote:
> On Mon, Jan 18, 2010 at 08:55, Mark Phippard  wrote:
>> On Mon, Jan 18, 2010 at 8:44 AM, Andy Levy  wrote:
 You should be able to just edit the %AppData%\Subversion\servers file
 on the client to tell it to use Serf over Neon (assuming your binaries
 support it).

 [global]
 http-library = serf

 If Anthill uses SVNKit then I am not sure what you can do other than
 increase the timeout on the server.
>>>
>>> I'll experiment some with the client config this morning, thanks.
>>>
>>> I'm not presently capturing User-Agent in my httpd logs - if I was,
>>> would that help me identify whether a client is using Serf or Neon?
>>
>> Neon is the default so it is pretty unlikely someone would be using
>> Serf.  I do not think the User-Agent identifies which library is used.
>>  It does however, tell you if SVNKit is being used.
>>
>> The request pattern in the logs between Serf and Neon is very
>> different and that would be the main giveaway.  An update with Neon is
>> mostly a single large REPORT request.  With Serf it is a small REPORT
>> request followed by a GET for each resource you need to update.
>
> Looks like Anthill can't use serf, my logs show the same pattern
> between yesterday & today. I know that the client config is being
> picked up from the right place because use-commit-times is being
> honored.
>
> Here's what I'm seeing:
>
> 172.30.5.40 - - [17/Jan/2010:20:56:02 -0500] "PROPFIND PATH HTTP/1.1" 207 736
> 172.30.5.40 - - [17/Jan/2010:20:56:02 -0500] "REPORT
> /Repos/Code/!svn/vcc/default HTTP/1.1" 200 883378845
>
> 883MB response being streamed back to the client, I guess the default
> 5 minute timeout isn't quite enough sometimes.
>
> The way I have things configured, Anthill is checking out a copy of
> the project while Tomcat is finishing the deployment of the previous
> build into its temp/working directory. Maybe these overlapped
> I/O-intensive tasks are slowing each other down? Often the first build
> succeeds, and subsequent ones fail. I'll have to try doing them
> independently later today.

It was definitely the I/O doing it. When doing the builds of each
project separately (not chaining them one after the other
automatically), everything runs properly. It's slowing the checkout
down enough that Apache times out.

Thanks for the pointer on neon vs. serf & the access log pattern. I
just wish I had a more automatic way to do the builds without a major
reconfiguration of that server.

Long local absolute path problem on windows (x64).

[Daniel Widenfalk]

Hi,

We've experienced a problem with checkouts to long local
absolute paths. I.e. we have a repository with test cases
and one of those test cases have a veeery long name for
regression test purposes. Now, checking out this file
usually works without a hitch but last week we hit a snag.

Subversion told us about problems creating files under the
.svn-tree. We did some fiddling with local and repository
paths and found that the issue seems to be related to local
paths becoming longer than 260-ish characters long. There's
a windows limit somewhere around there and that's probably
the root of the problem.

It seems that the lengths of both the local WC path and the
path in the repository are involved in this.

We have two WAs for this: 1) Reduce the length of the path
to the root of the wc or 2) Check out from deeper in the
repository, e.g. change from ^/trunk/ to ^/trunk/testcases.

Is this a known (and perhaps even documented) issue with the
Subversion client?

Do you want some sort of recipe to recreate the problem?

Regards
/Daniel Widenfalk