Russell Glaue <rglaue@cait.org> writes:
> Can anyone tell me how to add a comment to this issue (or any issue)
> in Issuezilla??
You need to "join the project" on the subversion web page.
> Transmitting file data
> ........................................................................ ........................................................................ ..........................svn:
> RA layer request failed
> svn: Commit failed (details follow):
> svn: MERGE request failed on
> '/svn/http-org.web-domain/trunk/webapps/de/vtlc/lev1'
> svn: MERGE of '/svn/http-org.web-domain/trunk/webapps/de/vtlc/lev1':
> timed out waiting for server (https://svn.cait.org)
If you send lots of items in a commit the server can take some time to
respond. It is possible to increase the client timeout, look for
http-timeout in ~/.subversion/servers.
> When the user runs 'svn status' his local repository shows that nothing
> had been committed to the repository. However when looking at the file
> on the server, they appear to be the files he committed and which he
> received the "RA Layer Error".
>
> [MaxOSX~] % svn status
> M acknowledge.jsp
> M content/les1/activity1.jsp
> M content/les1/activity2.jsp
> M content/les1/p1.jsp
> .
> ...yada...blah, blah, blah...
> ...yada...blah, blah, blah...more files....
> .
> A setup.jsp
> M started.jsp
Yes, the client assumes that the commit failed, so all the local
modifications remain.
> So the user runs 'svn update' and gets the message that the version
> already exists and thus local svn client does not do an update to the
> local repository.
You haven't given the exact error message. I assume that it refers to
items that are in state 'A' rather than state 'M'.
> The user then tries a svn cleanup. However there is no output and
> nothing is done to the local repository to fix the problem.
You should not need a cleanup. If you only have items in state 'M'
then I would expect update to work. However any items in state 'A'
will need to be removed using 'svn rm --force' before the update will
work. Yes, that is a bit messy. I suppose we could attempt some sort
of recovery, one option would be for the client to compare the
contents of the locally added file with those of the file being added
by the update, if the contents are identical then the obstructed error
could be avoided. Another option would be for the client to install
the text-base but leave the working copy unchanged. Keyword expansion
and eol translation would need to be considered in either case.
> It seems like all file changes are being committed to the server
> correctly, but the client times-out waiting for the server to send it
> feed back about the success/failure of the transaction/communication.
I think you are correct. Increase the client timeout, or buy a
faster server!
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 9 23:18:21 2003