You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2004/07/04 07:15:35 UTC
[svn] commit failure reported on success
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
Re: [svn] commit failure reported on success
Posted by Alex Karasulu <ao...@bellsouth.net>.
Hey thanks for the response. I guess this is something we should look
at more from the ASF infrastructure side.
Alex
On Mon, 2004-07-05 at 10:27, Ben Collins-Sussman wrote:
> On Sun, 2004-07-04 at 02:27, Alex Karasulu wrote:
> > 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.
>
> Alex, everything that happened to you is perfectly explainable.
>
> 1. Your client sent a commit.
>
> 2. Apache applied your commit to the repository.
>
> 3. Apache started to run a post-commit hook to send email, but (for some
> reason), it looks like this hook script never returned, or took
> incredibly long to complete.
>
> 4. The client (libneon) timed out waiting for a server response.
>
> Therefore, (1) no commit mail went out, (2) your client printed an
> error, and thinks the commit never happened, (3) the repository has the
> new revision anyway. When you try to update, you'll get conflicts,
> because the server is trying to send the same changes that already exist
> as 'local mods' in your working copy. It's probably best to just toss
> your working copy, or 'svn revert -R' to get rid of all your mods.
>
> The only real question here is why the hook script didn't return.
> Perhaps your 'post-commit' script should run another script
> backgrounded? That's what most people do.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [svn] commit failure reported on success
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sun, 2004-07-04 at 02:27, Alex Karasulu wrote:
> 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.
Alex, everything that happened to you is perfectly explainable.
1. Your client sent a commit.
2. Apache applied your commit to the repository.
3. Apache started to run a post-commit hook to send email, but (for some
reason), it looks like this hook script never returned, or took
incredibly long to complete.
4. The client (libneon) timed out waiting for a server response.
Therefore, (1) no commit mail went out, (2) your client printed an
error, and thinks the commit never happened, (3) the repository has the
new revision anyway. When you try to update, you'll get conflicts,
because the server is trying to send the same changes that already exist
as 'local mods' in your working copy. It's probably best to just toss
your working copy, or 'svn revert -R' to get rid of all your mods.
The only real question here is why the hook script didn't return.
Perhaps your 'post-commit' script should run another script
backgrounded? That's what most people do.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [svn] commit failure reported on success
Posted by Alex Karasulu <ao...@bellsouth.net>.
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
Re: [svn] commit failure reported on success
Posted by Alex Karasulu <ao...@bellsouth.net>.
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