# New Ticket Created by  James Keenan 
# Please include the string:  [perl #49224]
# in the subject line of all future correspondence about this issue. 
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49224 >


I am filing this ticket as a way of keeping track of some problems  
with our infrastructure rather than with our code.

Over the last several weeks I have experienced intermittent, but  
increasingly frequent, problems with commits to our SVN repository.   
The nutshell description of this problem is:

1.  I do 'svn commit'.
2.  The commit appears to hang at "Transmitting file data ...".  This  
hang can persist for up to 5 minutes.
3.  The commit appears to go through as evidenced by #parrot's  
svnbotl displaying the commit message.
4.  But what is returned to my sandbox is one of several error  
messages indicating that the commit has failed (examples below).
5.  If I subsequently do an 'svn update', then all the changes I just  
tried to commit are merged ('G') into my sandbox.
6.  Well, maybe not *all* the changes.  Step 5 works well for files  
which I am trying to update ('U').  However, new commits ('A') often  
are not.

Here are some examples:

I.
[parrot] 560 $ !557
svn ci -m "Update MANIFEST to reflect renumbering of tests in t/ 
configure/1??-*.t."
Sending        MANIFEST
Transmitting file data .subversion/libsvn_client/commit.c:765:  
(apr_err=175002)
svn: Commit failed (details follow):
subversion/libsvn_ra_dav/util.c:670: (apr_err=175002)
svn: MERGE request failed on '/parrot/trunk'
subversion/libsvn_ra_dav/util.c:656: (apr_err=175002)
svn: The MERGE request returned invalid XML in the response: XML  
parse error at line 32: not well-formed (invalid token) (/parrot/trunk)
[parrot] 561 $ svn up
G  MANIFEST
Updated to revision 24282.

II.
[li11-226:parrot] 656 $ svn ci MANIFEST.generated -m "Change entries  
for 2 files from config/gen/cpu/ to config/auto/cpu."
Sending        MANIFEST.generated
Transmitting file data .svn: Commit failed (details follow):
svn: MERGE request failed on '/parrot/trunk'
svn: MERGE of '/parrot/trunk': 200 OK (https://svn.perl.org)
[li11-226:parrot] 657 $ svn up
G    MANIFEST.generated
Updated to revision 24270.

III.
While using svn merge to update a branch sandbox with submissions to  
trunk between two revisions marked by tags:

U    /home/jimk/work/explicitconf/languages/eclectus/docs/eclectus.pod
U    /home/jimk/work/explicitconf/languages/eclectus/compiler.scm
U    /home/jimk/work/explicitconf/languages/eclectus/tests-driver.scm
Sandbox for explicitconf branch has been updated by merging in head  
of trunk
svn: MERGE request failed on '/parrot/tags'
svn: MERGE of '/parrot/tags': 200 OK (https://svn.perl.org)
Unable to delete superfluous tag explicitconf-24170 at /home/jimk/bin/ 
perl/svn_synch.pl line 75

And when I subsequently go to commit the updates to the branch:

Adding         tools/dev/pbc_to_c_gen.pl
Transmitting file  
data ................................................................... 
.....................................................................svn 
: Commit failed (details follow):
svn: MERGE request failed on '/parrot/branches/explicitconf'
svn: MERGE of '/parrot/branches/explicitconf': 200 OK (https:// 
svn.perl.org)

Followed by an unsuccessful 'svn up':

[li11-226:explicitconf] 734 $ svn up
D    config/auto/cpu.pm
A    config/auto/cpu.pm
G    config/auto/aio.pm
G    config/auto/gdbm.pm
G    config/auto/funcptr.pm
G    config/auto/jit.pm
G    config/auto/format.pm
G    config/auto/perldoc.pm
svn: Failed to add file 'config/auto/arch.pm': object of the same  
name already exists

At which point I decide to nuke my sandbox and lose any uncommitted  
changes.


At first I thought it was something *I* was doing wrong.  However,
(a) It can happen regardless of whether I'm working from my iBook or  
my Linux server;
(b) It happens on completely freshly checked-out sandboxes from trunk.
(c) pmichaud has reported similar problems.

I've informed Ask of these problems.  I don't think they are  
connected to the maintenance work which Robert and Ask were doing  
earlier this weekend, because I experienced them both before and  
after the maintenance work.

Are other people experiencing this problem?

Thank you very much.


Reply via email to