[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[svn] commit failure reported on success

From: Alex Karasulu <aok123_at_bellsouth.net>
Date: 2004-07-04 09:15:35 CEST


I've been observing some odd behavoir when performing commits that take
a very long time due to the number of operations they are associated

I just commited a reverse merge within the following repository


I used the following merge command on my working copy to reverse merge
the changes from revision 22486 to 22485:

svn merge -r 22486:22485 .

The subsequent commit operation also within this directory returned the
following commit failure message:

svn: Commit failed (details follow):
svn: MERGE request failed on
'/repos/asf/incubator/directory/eve/trunk/frontend'svn: MERGE of
'/repos/asf/incubator/directory/eve/trunk/frontend': timed out waiting
for server (https://svn.apache.org)
svn: Your commit message was left in a temporary file:
svn: '/home/akarasulu/projects/eve/trunk/svn-commit.tmp'

I checked the repository on the server using viewcvs and the commit in
fact succeeded with a revision number of 22520. Here's a link in
viewcvs to one of the reverse merged files showing the log message I
used for the commit:


The merge seemed to have worked flawlessly from what I can observe on
the server yet svn is reporting a failure on commit. Could this be a
bug? Perhaps there are some httpd configuration settings causing the
erroneous failure message when in fact svn is succeeding: those settings
associated with timeouts perhaps (I'm not well versed enough in httpd to
figure this out).

Everything looks fine on the server but the working copy is really
busted. An svn update on it gives me the following error:

svn: Failed to add directory 'processor': object of the same name
already exists

So the working copy thinks the commit did not make it through I guess
and its out of synch with the server. Furthermore the log message never
shows the newly committed revision obviously. Here's the first few log
messages with a svn log:

r22486 | akarasulu | 2004-07-02 12:47:19 -0400 (Fri, 02 Jul 2004) | 1

Merged consolidation branch changes r22350:22485 into trunk
r21342 | akarasulu | 2004-06-16 00:53:40 -0400 (Wed, 16 Jun 2004) | 1

ignore idea generated files
r21341 | akarasulu | 2004-06-16 00:29:56 -0400 (Wed, 16 Jun 2004) | 2

Found various problems due to changes in excalibur.

Then just to be complete if I do a recursive revert on the directory
like so:

svn revert -R .

All appears well until I perform an svn up which gives me the same
update error that I got before doing the revert operation:

svn: Failed to add directory 'processor': object of the same name
already exists

At this point all I know is this is odd behavoir for our subversion
setup at the ASF: I've never had any problems other than my user related
errors when it comes to svn. She's never let me down even when she says
she has :-).

This problem occured before when I commited a bunch of changes that
actually took me from revision 22485 to 22486. No wonder the same
problem was encountered when going back. The flurry of changes
representing this forward merge operation occurred on the
'consolidation' branch of the eve trunk here between revisions
22350-22485. Then the commit for 22486 gave me the same commit error as
the reverse merge commit above.

Perhaps I could have avoided this by performing a bunch of smaller
commits after the merge on subdirectories. I'm sure the deep nasty
directory nesting that I use helped the operation time out :(.

Any ideas on what might be causing this problem?


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jul 4 09:14:45 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.