Ok this is it I promise :-). More info again.
The svn commit email failed to go out. I know this for sure (rather than
a delay being the issue) because I just generated revision 22521 which I
just recieved: 22520 on the failed commit never made it out the door.
This may be important maybe not.
On Sun, 2004-07-04 at 03:20, Alex Karasulu wrote:
> 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:26:38 2004