On Mon, Jan 26, 2009 at 4:21 PM, Brian Rieck <BRieck_at_sandcherry.com> wrote:
> Thanks for the quick reply Paul!
>
> I have not altered the output in any way. The version of svn was 1.5.4 when the repo was created. After reproducuing the problem a couple times with 1.5.4 I upgraded my test server and client to 1.5.5 just to see if it might have an impact on this issue. It did not.
>
> So to recreate the problem that the developer was seeing on the production server I essentially did this:
>
> 1) Did a restore of a backup of our production server to a test server
> 2) svn cp <url_to_repo>/branches/4.1.00_Dev <url_to_repo>/branches/user_branches/Camille
> 3) svn co <url_to_new_camille_branch>
> 4) changed a couple files in the Camille branch, committed them
> 5) svn cp <url_to_repo>/branches/user_branches/Camille <url_to_repo>/branches/user_branches/Jeff3
Brian,
Is there any explicit mergeinfo on any of these paths (you can check
with a svn propget svn:mergeinfo)?
<url_to_repo>
<url_to_repo>/branches
<url_to_repo>/branches/user_branches
Since <url_to_repo>/branches/user_branches/Jeff3 has no explicit
mergeinfo, it will inherit the mergeinfo from its nearest parent with
mergeinfo. Based only on your naming scheme I'd be suprised to find
that any of these paths *do* have mergeinfo, but I won't to rule out a
bad mergeinfo value on some parent of Jeff3's as a cause of this
problem.
> 6) svn co <url_to_new_jeff3_branch>
> 7) svn merge <url_to_new_camille_branch> <wc_path_to_jeff3>
In steps 5-7 you have basically done this:
Copy A to B
Checkout B
Merge all available changes from A to B
Which, unless you made some more changes to under A after copying it,
is a no-op; there is nothing to merge. Was this intentional? Should
step 4 and 5 be swapped maybe?
> As part of step 4 I believe I did a move on a file to rename it. Other than step 4 I didn't do anything in my WC.
The WC-to-WC copies must have happened prior to your recreation
effort. Could you run 'svn log -vq' on some of the paths with empty
mergeinfo? Somewhere in thier history should be evidence of a
WC-to-WC copy/move, something like this (revisions, author, source
name obviously made up):
------------------------------------------------------------------------
r45115 | programmerbob | 2008-05-23 23:09:08 -0400 (Fri, 23 May 2008)
Changed paths:
A /camille/platform/src/java/com/sandcherry/tools/common/database/model/vmc/UserProperties.hbm.xml
(from /camille/platform/src/java/com/sandcherry/tools/common/database/model/vmc/UserPropertiesFile.hbm.xml:
45001)
------------------------------------------------------------------------
Then do svn diff -rr45114:r45115
/camille/platform/src/java/com/sandcherry/tools/common/database/model/vmc/UserPropertiesFile.hbm.xml,
was any empty mergeinfo added?
> The really weird part of this to me is that doing the merge anywhere lower than the root works and then I can merge at the root.
Anywhere below the root? You are able to do this merge successfully:
'svn merge <url_to_new_camille_branch>/platform
<wc_path_to_jeff3>/platform'? The reason I ask is that since the only
subtrees with explict mergeinfo under wc_path_to_jeff3 are deeper than
wc_path_to_jeff3/platform. So a merge to wc_path_to_jeff3 or
wc_path_to_jeff3/platform should attempt to merge the same set of
revisions and should almost certainly encounter the same parsing
error.
Paul
> Some other things that may or may not be relevant but that I'll throw out there anyway:
>
> -there are over 50,000 items in this repository
> -this is a young repository. We have only been using svn for about 1 month
> -no one else has access to the test server so there are no changes except the couple of changes I made in step 4 above to any of the branches
> -client is Win32, server is Linux
>
> Thanks again for your attention.
>
> -Brian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1056255
Received on 2009-01-26 23:36:05 CET