"Steve Williams" <stevewilliams@kromestudios.com> writes:
> I disabled http-compression by setting the registry value as shown in the
> Book. The servers file was nowhere to be found in $APPDATA, as apparently
> there should have been a file created when svn was run for the first time.
> There was a proxies file, but no servers file.
This worries me.
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Tigris.org\Subversion\Servers\DEFAULT]
> "http-compression"="no"
>
> No other servers files or entries are in HKCU or $APPDATA folders.
Are you running a recent svn? The 'proxies' file is what the
'servers' file used to be called a long, long time ago.
It worries me that no 'servers' file exists at all...
>
> A large commit (285MB in 9,761 files) still failed with the MERGE request
> timeout.
>
> F:\ty2\data\Data>svn commit Cutscenes -m "Initial commit"
> [directory and files committed]
> svn: RA layer request failed
> svn: Commit failed (details follow):
> svn: MERGE request failed on '/repos/ty2/trunk/data/Data'
> svn: MERGE of '/repos/ty2/trunk/data/Data': timed out waiting for server
> (http://julius)
Are you *sure* that apache wasn't trying to compress the response?
Given my commentary above, I have little faith that your (possibly
old) svn client is paying attention to the registry value you set.
As Sander Striker said, the best thing to do is to outright disable
compression within your httpd.conf's svn <Location>. That's the only
we can be *sure* there's no apache compression happening. This MERGE
timeout sure looks like compression is still happening on the server.
> F:\ty2\data\Data>svn commit Cutscenes -m "Initial commit"
> Adding Cutscenes
> svn: RA layer request failed
> svn: Commit failed (details follow):
> svn: MKCOL of
> /repos/ty2/!svn/wrk/7f7e3478-a219-d84a-9ef6-7128675f8c64/trunk/data/Data/Cut
> scenes: 405 Method Not Allowed (http://julius)
Well, sure. The commit *happened* in the repository, most likely.
The MERGE response is a large response from the server to the client,
whereby the server tells the client "commit succeeded, here's a bunch
of metadata to stuff in your working copy." When the MERGE fails, the
working copy is left sitting around with the same local mods, unaware
that the commit suceeded. So when you retry the commit, the MKCOL
(mkdir) fails, because the directory already exists in the repository.
> Try to get an update from the repository.
>
> F:\ty2\data\Data>svn update Cutscenes
> svn: Filesystem has no item
> svn: REPORT request failed on '/repos/ty2/!svn/vcc/default'
> svn:
> file not found: revision `0', path `/trunk/data/Data'
Wow, so what happened here is that your client told the server it had
"revision 0 of /trunk/data/Data", and the server choked on it. This
makes it absolutely clear to me that you're using an old version of
svn. Upgrade to 0.25, please please please. We can't go chasing down
bugs on old releases.
>
> I can no longer commit nor update that directory. Possibly time to start a
> new repository again.
I doubt there's anything wrong with your repository at all. The
commit happened, end of story. Your working copy, however, might be
hosed. Do a fresh checkout.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 18 04:33:57 2003