Hi Stefan,
I just saw your message so I won't post to the dev list just yet. These
are the details I was going to post:
----------START----------
We are using Apache 1.8.0 clients, CollabNet Subversion native binaries
1.8.1 (and CollabNet Subversion Edge 4.0.1). I am working on OSX 10.8.4
and I am using the apache source compiled with the following instructions:
http://samoldak.com/updating-to-svn-1-8-for-mac-os-x-10-8/ (this uses
serf). We have found the same issue on a packaged version of the svn 1.8
client from Wandisco.
The issue we encountered is that SVN is trying to do a reintegrate when
attempting to merge a trunk project to a branch of that same project and
it (incorrectly) complains about missing revisions and some paths in the
error message are truncated.
Our setup is a fairly straightforward configuration, we have trunk
projects in $SVNROOT/svn/trunk/<projectname> and branches in
$SVNROOT/svn/branches/<projectname>/features/<branchname> so for example
if we have a project called my_project and branch of this project called
my_project_branch, they would be in the repository in the following paths
$SVNROOT/trunk/my_project and
$SVNROOT/branches/my_project/features/my_project_branch. The $SVNROOT is
just a variable we use that corresponds the repository URL e.g.
https://our.svn.servername/svn.
Recently when we attempted to merge a trunk project to a branch (in
preparation of doing a merge of the branch back to trunk) we are got
errors like the following:
$ svn merge ^/trunk/my_project .
svn: E195016: Reintegrate can only be used if revisions 4401 through 4579
were previously merged from
https://our.svn.servername/svn/branches/my_project/features/my_project_bran
ch to the reintegrate source, but this is not the case:
trunk/my_project
Missing ranges: /trunk/my_projec:4485
Missing ranges:
/trunk/my_project:4407-4408,4431,4442-4444,4485,4524,4532-4533
I was not expecting this error because we had previously merged the trunk
project to the branch and merged the branch back down to trunk
successfully so as far as I'm aware there should be no missing revisions.
Also I am surprised that a reintegrate merge is being attempted when
trying to merge from the trunk project to the branch project because, as I
understand it, the reintegrate should only happen when merging content
from a branch to a project that the branch was created from. As if you
looking at the first line missing ranges section it has truncated the last
letter of the path.
I have run the svn merginfo command which gave the following output:
$ svn mergeinfo ^/trunk/my_project .
youngest common ancestor
| last full merge
| | tip of branch
| | | repository path
4400 4579
| |
-------| |------------ trunk/my_project
\ /
\ /
--| |------------
branches/my_project/features/my_project_branch
| |
4531 4579
And when I do the svn merge info on trunk I get the following:
$ svn mergeinfo ^/branches/my_project/features/my_project_branch
^/trunk/my_project
youngest common ancestor
| last full merge
| | tip of branch
| | | repository path
4400 4531 4579
| | |
--| |------------
branches/my_project/features/my_project_branch
/ \
/ \
-------| |------------ trunk/my_project
|
4579
I tried to do the same merge using an SVN 1.6 client (to checkout and
merge) and the merge worked as expected so I suspect that this a client
bug.
Could you please help to diagnose this issue? Please let me know if any
further information is required? Unfortunately I have not be able to come
with a deterministic set of steps to reproduce the issue. I have had to
work around the issue by using the r option to svn merge e.g. svn
r4400:HEAD ^/trunk/my_project .
----------END----------
I'm not sure I understand what you mean by "Does the corruption happen
also if you use file:// URLs on the server during checkout/merge, instead
of http:// ?". Our SVN server is remote to our development machine so the
only way I do the merge is using a URL with http:// into a local working
copy (WC) so that I can resolve in the WC any conflicts before committing.
Could explain a bit more what you mean by this so I can send on some more
information?
Many Thanks,
Stefan
On 16/09/2013 10:34, "Stefan Sperling" <stsp_at_elego.de> wrote:
>On Fri, Sep 13, 2013 at 04:16:17PM -0400, Andrew Reedick wrote:
>> > -----Original Message-----
>> > From: Goor, Stefan [mailto:SGoor_at_thetasgroup.com]
>> > Is this a bug? Is it something we are doing wrong? Is there any
>> > information we could send that would help diagnose and prevent the
>> > issue?
>> >
>>
>> No idea. But I posted about the missing char issue a couple of days
>>ago: http://svn.haxx.se/users/archive-2013-09/0116.shtml
>>
>> It's either a harmless presentation error, or the missing char implies
>>a malformed pathname that is possibly mucking up the merge analysis?
>>
>
>Hi Andrew,
>
>did you have time to answer Ivan's questions from this post?
>http://svn.haxx.se/users/archive-2013-09/0142.shtml
>
>Knowing where the mergeinfo corruption starts occurring would
>help us greatly with hunting down the issue.
>
>Does the corruption happen also if you use file:// URLs on the server
>during checkout/merge, instead of http:// ?
Received on 2013-09-16 12:04:13 CEST