Oh one more thing to note although not surprising at all.
I just blew away the frontend directory in my working copy (rm -rf
frontend) and then did an update. The update pulled down the perfectly
merged result as revision 22520 as witnessed with the following
successful update message:
[omitting all the stuff pulled down]
Updated to revision 22520.
Alex
On Sun, 2004-07-04 at 03:15, Alex Karasulu wrote:
> Hello,
>
> 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
> with.
>
> I just commited a reverse merge within the following repository
> directory:
>
> https://svn.apache.org/repos/asf/incubator/directory/eve/trunk/frontend
>
> 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:
>
> http://svn.apache.org/viewcvs.cgi/incubator/directory/eve/trunk/frontend/buffer/merlin-impl/?root=Apache-SVN
>
> 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
> line
>
> Merged consolidation branch changes r22350:22485 into trunk
> ------------------------------------------------------------------------
> r21342 | akarasulu | 2004-06-16 00:53:40 -0400 (Wed, 16 Jun 2004) | 1
> line
>
> ignore idea generated files
> ------------------------------------------------------------------------
> r21341 | akarasulu | 2004-06-16 00:29:56 -0400 (Wed, 16 Jun 2004) | 2
> lines
>
> 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?
>
> Alex
>
>
---------------------------------------------------------------------
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:20:08 2004