You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Goor, Stefan" <SG...@thetasgroup.com> on 2013/09/13 17:40:19 UTC
SVN merge attempting to reintegrate on a merge to a branch
Hi,
We are encountering an issue when trying to merge trunk to a branch. We originally posted this issue to the CollabNet forums (http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=499929) but they suggested we should contact this list.
We maintain a few branches from our trunk project and we periodically merge back and forth between the trunk project and the branches. When we have work in a branch that we need to reintegrate to trunk we first merge trunk up to the branch and then merge (reintegrate) the branch back down to trunk. We are using SVN version 1.8 so we no longer specify the —reintegrate option as from what I understand the client should now identify what type of merge to do. This process had been working well for until recently when we started getting some errors.
We are using Apache 1.8.0 clients, CollabNet Subversion native binaries 1.8.1 (and CollabNet Subversion Edge 4.0.1). 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 $SVNROOT/trunk/my_project .
svn: E195016: Reintegrate can only be used if revisions 4401 through 4545 were previously merged from https://our.svn.servername/svn/branches/my_project/features/my_project_branch to the reintegrate source, but this is not the case:
trunk/my_project
Missing ranges: /trunk/my_project: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, the reintegrate should only happen when merging content from a branch to a project that the branch was created from.
I have run the svn merginfo command which gave the following output:
$ svn mergeinfo $SVNROOT/trunk/my_project .
youngest common ancestor
| last full merge
| | tip of branch
| | | repository path
4400 4545
| |
-------| |------------ trunk/my_project
\ /
\ /
--| |------------ branches/my_project/features/my_project_branch
| |
4531 4541
Can you please help us track down and resolve the issue?
I'm not sure if it makes any difference but the branch was created using the repository browser in eclipse with the Subclipse plugin v3.0.0 using Subversion Client Adapter version 1.8.6
Many Thanks,
Stefan
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by "Goor, Stefan" <SG...@thetasgroup.com>.
Hi Stefan,
That makes sense, my understand of the process was a bit off but I see
what you mean.
I'm currently looking to test the fix you sent for the client. I will
respond as soon as I have tested it.
Many Thanks for your help,
Stefan
On 16/09/2013 15:33, "Stefan Sperling" <st...@elego.de> wrote:
>On Mon, Sep 16, 2013 at 12:06:46PM +0000, Goor, Stefan wrote:
>> I think the fact the error related to doing a reintegrate merge is also
>> wrong. Given that the merge was from a trunk project (that the branch
>>was
>> created from) to the the branch, should it not have been attempting a
>> regular merge? It is my understanding that a reintegrate merge is done
>> (automatically since 1.8) when bringing a branch back into the project
>>it
>> was created from.
>
>It's a little more complex than that.
>
>There is no reason to be surprised if the new 'complete merge' in
>Subversion 1.8 attempts to reintegrate the trunk into a branch.
>Whether a sync or reintegrate merge is performed depends on prior
>merge history. A reintegrate merge is performed whenever a merge's
>direction differs from the direction of the previous merge. A sync
>merge is performed whenever the merge direction stays the same.
>
>A simple example:
>
>Create branch B from trunk.
>
>Merges performed, in sequence: Merge type selected by SVN:
>
>Merge from trunk to B sync merge
>Merge from B to trunk reintegrate merge
>Merge from B to trunk sync merge
>Merge from B to trunk sync merge
>Merge from B to trunk sync merge
>Merge from trunk to B reintegrate merge
>Merge from trunk to B sync merge
>Merge from trunk to B sync merge
>Merge from B to trunk reintegrate merge
>Merge from B to trunk sync merge
>
>Can you see the pattern?
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Sep 16, 2013 at 12:06:46PM +0000, Goor, Stefan wrote:
> I think the fact the error related to doing a reintegrate merge is also
> wrong. Given that the merge was from a trunk project (that the branch was
> created from) to the the branch, should it not have been attempting a
> regular merge? It is my understanding that a reintegrate merge is done
> (automatically since 1.8) when bringing a branch back into the project it
> was created from.
It's a little more complex than that.
There is no reason to be surprised if the new 'complete merge' in
Subversion 1.8 attempts to reintegrate the trunk into a branch.
Whether a sync or reintegrate merge is performed depends on prior
merge history. A reintegrate merge is performed whenever a merge's
direction differs from the direction of the previous merge. A sync
merge is performed whenever the merge direction stays the same.
A simple example:
Create branch B from trunk.
Merges performed, in sequence: Merge type selected by SVN:
Merge from trunk to B sync merge
Merge from B to trunk reintegrate merge
Merge from B to trunk sync merge
Merge from B to trunk sync merge
Merge from B to trunk sync merge
Merge from trunk to B reintegrate merge
Merge from trunk to B sync merge
Merge from trunk to B sync merge
Merge from B to trunk reintegrate merge
Merge from B to trunk sync merge
Can you see the pattern?
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by "Goor, Stefan" <SG...@thetasgroup.com>.
Hi Stefan,
I tried the fix below and it solved the issue of the truncated path in the
missing ranges section:
$ svn merge ^/trunk/my_project .
svn: E195016: Reintegrate can only be used if revisions 4401 through 4598
were previously merged from
https://our.svn.servername/REPO/branches/my_project/features/my_project_bra
nch to the reintegrate source, but this is not the case:
trunk/my_project
Missing ranges:
/trunk/my_project:4407-4408,4431,4442-4444,4485,4524,4532-4534,4538,4582
However, I still don't understand why the branch thinks it's missing these
revisions. I tried to manually merge these revisions into the trunk
project but none of the revisions had any effect on the working copy of
the trunk project. There were no changes or svn:mergeinfo property
changes because these revision were previously seen in a merge we did a
little while ago:
$ svn merge -r4407:4408 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4408 into '.':
U .
$ svn merge -c4431 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4431 into '.':
U .
$ svn merge -r4442:4444 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4443 through r4444 into '.':
U .
$ svn merge -c4485 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4485 into '.':
U .
$ svn merge -c4524 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4524 into '.':
U .
$ svn merge -r4532:4534 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4533 through r4534 into '.':
U .
$ svn merge -c4538 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4538 into '.':
U .
$ svn merge -c4582 ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4582 into '.':
U .
$ svn stat
$
$ svn pg svn:mergeinfo . | grep "my_project_branch"
/branches/my_project/features/my_project_branch:4401-4590
$ cd $BRANCH_PROJECT_PATH
$ svn pg svn:mergeinfo . | grep "\/trunk\/my_project"
/trunk/my_project:4401-4587
Is there anyway for us to identify what is wrong? We have seen this issue
on a few branch recently and we would like to avoid / correct the issue if
possible. Would the above truncated path issue have caused this issues
also? If we patch our SVN client and recreate a new branch for this
feature do you think that would avoid these problems in the future?
Could we have done something wrong with a merge to produce this? We tend
to use a simple enough merging and branching proceedure and it had worked
fine until recently so I'd like to figure out if we need to change the way
we are doing things.
Many Thanks for all your help,
Stefan
On 16/09/2013 15:26, "Stefan Sperling" <st...@elego.de> wrote:
>On Mon, Sep 16, 2013 at 11:51:30AM +0000, Goor, Stefan wrote:
>> Sorry for that, I should have spotted the missing slash! The local
>>merge
>> gave the same result:
>>
>> C:\Users\Administrator\my_project_branch>C:\csvn\bin\svn merge
>> "file:///C:/csvn/data/r
>> epositories/REPO/trunk/my_project" .
>> svn: E195016: Reintegrate can only be used if revisions 4401 through
>>4587
>> were p
>> reviously merged from
>> file:///C:/csvn/data/repositories/REPO/branches/my_project/f
>> eatures/my_project_branch 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-453
>> 3
>>
>> Please let me know if I can post any further information to help
>>identify
>> the issue.
>
>Thanks!
>
>Bert Huijben pointed out to me a way to reproduce this problem
>with the svn.apache.org repository. Using his reproduction recipe
>I could spot the problem and fix it: http://svn.apache.org/r1523666
>
>This wasn't a cosmetic issue, but caused actual mis-detection of
>missing ranges. Whether or not that patch fixes your merge problem
>remains to be seen -- it all depends on your merge history. However,
>with the above fix (patch below) the obvious corrupted path issue
>should disappear.
>
>Can you try this patch?
>
>Index: subversion/libsvn_client/merge.c
>===================================================================
>--- subversion/libsvn_client/merge.c (revision 1523568)
>+++ subversion/libsvn_client/merge.c (working copy)
>@@ -10715,7 +10715,7 @@ log_find_operative_revs(void *baton,
>
> suffix = svn_relpath_skip_ancestor(subtree_missing_this_rev,
> source_rel_path);
>- if (suffix)
>+ if (suffix && suffix[0] != '\0')
> {
> missing_path = apr_pstrmemdup(pool, path,
> strlen(path) -
>strlen(suffix) - 1);
>
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Sep 16, 2013 at 11:51:30AM +0000, Goor, Stefan wrote:
> Sorry for that, I should have spotted the missing slash! The local merge
> gave the same result:
>
> C:\Users\Administrator\my_project_branch>C:\csvn\bin\svn merge
> "file:///C:/csvn/data/r
> epositories/REPO/trunk/my_project" .
> svn: E195016: Reintegrate can only be used if revisions 4401 through 4587
> were p
> reviously merged from
> file:///C:/csvn/data/repositories/REPO/branches/my_project/f
> eatures/my_project_branch 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-453
> 3
>
> Please let me know if I can post any further information to help identify
> the issue.
Thanks!
Bert Huijben pointed out to me a way to reproduce this problem
with the svn.apache.org repository. Using his reproduction recipe
I could spot the problem and fix it: http://svn.apache.org/r1523666
This wasn't a cosmetic issue, but caused actual mis-detection of
missing ranges. Whether or not that patch fixes your merge problem
remains to be seen -- it all depends on your merge history. However,
with the above fix (patch below) the obvious corrupted path issue
should disappear.
Can you try this patch?
Index: subversion/libsvn_client/merge.c
===================================================================
--- subversion/libsvn_client/merge.c (revision 1523568)
+++ subversion/libsvn_client/merge.c (working copy)
@@ -10715,7 +10715,7 @@ log_find_operative_revs(void *baton,
suffix = svn_relpath_skip_ancestor(subtree_missing_this_rev,
source_rel_path);
- if (suffix)
+ if (suffix && suffix[0] != '\0')
{
missing_path = apr_pstrmemdup(pool, path,
strlen(path) - strlen(suffix) - 1);
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by "Goor, Stefan" <SG...@thetasgroup.com>.
Hi Stefan,
In your earlier email you mentioned:
>We want to know why you are seeing:
>
>> Missing ranges: /trunk/my_projec:4485
>
>which lacks a trailing 't' in the path name.
>
>That's the only obviously wrong thing in your problem report.
I think the fact the error related to doing a reintegrate merge is also
wrong. Given that the merge was from a trunk project (that the branch was
created from) to the the branch, should it not have been attempting a
regular merge? It is my understanding that a reintegrate merge is done
(automatically since 1.8) when bringing a branch back into the project it
was created from.
Many Thanks,
Stefan
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by "Goor, Stefan" <SG...@thetasgroup.com>.
Hi Stefan,
On 16/09/2013 12:41, "Stefan Sperling" <st...@elego.de> wrote:
>On Mon, Sep 16, 2013 at 11:31:09AM +0000, Goor, Stefan wrote:
>> Hi Stefan,
>>
>> Thanks for your email.
>>
>> The out put of those commands is below:
>[...]
>
>Assuming the output was sanitised correctly, it looks ok.
Yes I sanitised the project names but I diffed the output and the local
and remote command responses were identical.
>
>> I tried to run the checkout on the server using the file:// protocol but
>> it won't allow me to use it as I got the following error:
>>
>> C:\Users\Administrator> C:\csvn\bin\svn co
>> "file://C:/csvn/data/repositories/REPO"
>> svn: E180001: Unable to connect to a repository at URL
>> 'file://C:/csvn/data/repositories/REPO
>
>You need 3 leading slashes. Two for the protocol prefix, plus one for
>the root directory to create an absolute path in the URL. So try this:
> file:///C:/csvn/data/repositories/REPO
Sorry for that, I should have spotted the missing slash! The local merge
gave the same result:
C:\Users\Administrator\my_project_branch>C:\csvn\bin\svn merge
"file:///C:/csvn/data/r
epositories/REPO/trunk/my_project" .
svn: E195016: Reintegrate can only be used if revisions 4401 through 4587
were p
reviously merged from
file:///C:/csvn/data/repositories/REPO/branches/my_project/f
eatures/my_project_branch 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-453
3
Please let me know if I can post any further information to help identify
the issue.
Many Thanks,
Stefan
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Sep 16, 2013 at 11:31:09AM +0000, Goor, Stefan wrote:
> Hi Stefan,
>
> Thanks for your email.
>
> The out put of those commands is below:
[...]
Assuming the output was sanitised correctly, it looks ok.
> I tried to run the checkout on the server using the file:// protocol but
> it won't allow me to use it as I got the following error:
>
> C:\Users\Administrator> C:\csvn\bin\svn co
> "file://C:/csvn/data/repositories/REPO"
> svn: E180001: Unable to connect to a repository at URL
> 'file://C:/csvn/data/repositories/REPO
You need 3 leading slashes. Two for the protocol prefix, plus one for
the root directory to create an absolute path in the URL. So try this:
file:///C:/csvn/data/repositories/REPO
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by "Goor, Stefan" <SG...@thetasgroup.com>.
Hi Stefan,
Thanks for your email.
The out put of those commands is below:
$ svn propget svn:mergeinfo ^/trunk/my_project
/branches/my_project/features/other_branch_1:3057-3653
/branches/my_project/features/other_branch_2:2197-3641
/branches/my_project/features/other_branch_3:3774-3932
/branches/my_project/features/other_branch_4:2093-3661
/branches/my_project/features/other_branch_5:3693-3766
/branches/my_project/features/other_branch_6:3962-4304
/branches/my_project/features/other_branch_7:3945-4220,4223-4398
/branches/my_project/features/other_branch_8:3214-4181
/branches/my_project/features/other_branch_9:1204-2255
/branches/my_project/features/other_branch_10:3280-3940
/branches/my_project/features/my_project_branch:4401-4533 //this is the
branch with the issue
/branches/my_project/features/other_branch_11:294-1048
/branches/my_project/features/other_branch_12:294-1214
/branches/my_project/features/other_branch_13:583-808
/branches/my_project/features/other_branch_14:3220-3634
/branches/my_project/features/other_branch_15:4002-4385
/branches/my_project/features/other_branch_16:4175-4314
/branches/my_project/features/other_branch_17:4172-4292
/branches/my_project/features/other_branch_18:2356-2911
/branches/my_project/patches/patch_1:296-4579
/branches/my_project/patches/patch_2:825-942
/branches/my_project/patches/patch_3:1154,1222-4580
/branches/my_project/patches/patch_4:1533-1932
/branches/my_project/patches/patch_5:2538-4581
/branches/my_project/patches/patch_6:3181-3277
/branches/features/old_branch_1:55-293
/branches/features/old_branch_2:80-293
/branches/patches/old_patch_1:33-295
$ svn propget svn:mergeinfo
^/branches/my_project/features/my_project_branch
/branches/my_project/features/other_branch_1:3057-3653
/branches/my_project/features/other_branch_2:2197-3641
/branches/my_project/features/other_branch_3:3774-3932
/branches/my_project/features/other_branch_4:2093-3661
/branches/my_project/features/other_branch_5:3693-3766
/branches/my_project/features/other_branch_6:3962-4304
/branches/my_project/features/other_branch_7:3945-4220,4223-4398
/branches/my_project/features/other_branch_8:3214-4181
/branches/my_project/features/other_branch_9:1204-2255
/branches/my_project/features/other_branch_10:3280-3940
/branches/my_project/features/other_branch_11:294-1048
/branches/my_project/features/other_branch_12:294-1214
/branches/my_project/features/other_branch_13:583-808
/branches/my_project/features/other_branch_14:3220-3634
/branches/my_project/features/other_branch_15:4002-4385
/branches/my_project/features/other_branch_16:4175-4314
/branches/my_project/features/other_branch_17:4172-4292
/branches/my_project/features/other_branch_18:2356-2911
/branches/my_project/patches/patch_1:296-3919
/branches/my_project/patches/patch_2:825-942
/branches/my_project/patches/patch_3:1154,1222-3920
/branches/my_project/patches/patch_4:1533-1932
/branches/my_project/patches/patch_5:2538-3921
/branches/my_project/patches/patch_6:3181-3277
/branches/features/old_branch_1:55-293
/branches/features/old_branch_2:80-293
/branches/patches/old_patch_1:33-295
/trunk/my_project:4401-4525
$ svn propget svn:mergeinfo working_copy_of_trunk_my_project
/branches/my_project/features/other_branch_1:3057-3653
/branches/my_project/features/other_branch_2:2197-3641
/branches/my_project/features/other_branch_3:3774-3932
/branches/my_project/features/other_branch_4:2093-3661
/branches/my_project/features/other_branch_5:3693-3766
/branches/my_project/features/other_branch_6:3962-4304
/branches/my_project/features/other_branch_7:3945-4220,4223-4398
/branches/my_project/features/other_branch_8:3214-4181
/branches/my_project/features/other_branch_9:1204-2255
/branches/my_project/features/other_branch_10:3280-3940
/branches/my_project/features/my_project_branch:4401-4533 //this is the
branch with the issue
/branches/my_project/features/other_branch_11:294-1048
/branches/my_project/features/other_branch_12:294-1214
/branches/my_project/features/other_branch_13:583-808
/branches/my_project/features/other_branch_14:3220-3634
/branches/my_project/features/other_branch_15:4002-4385
/branches/my_project/features/other_branch_16:4175-4314
/branches/my_project/features/other_branch_17:4172-4292
/branches/my_project/features/other_branch_18:2356-2911
/branches/my_project/patches/patch_1:296-4579
/branches/my_project/patches/patch_2:825-942
/branches/my_project/patches/patch_3:1154,1222-4580
/branches/my_project/patches/patch_4:1533-1932
/branches/my_project/patches/patch_5:2538-4581
/branches/my_project/patches/patch_6:3181-3277
/branches/features/old_branch_1:55-293
/branches/features/old_branch_2:80-293
/branches/patches/old_patch_1:33-295
$ svn propget svn:mergeinfo working_copy_of_branches_my_project
/branches/my_project/features/other_branch_1:3057-3653
/branches/my_project/features/other_branch_2:2197-3641
/branches/my_project/features/other_branch_3:3774-3932
/branches/my_project/features/other_branch_4:2093-3661
/branches/my_project/features/other_branch_5:3693-3766
/branches/my_project/features/other_branch_6:3962-4304
/branches/my_project/features/other_branch_7:3945-4220,4223-4398
/branches/my_project/features/other_branch_8:3214-4181
/branches/my_project/features/other_branch_9:1204-2255
/branches/my_project/features/other_branch_10:3280-3940
/branches/my_project/features/other_branch_11:294-1048
/branches/my_project/features/other_branch_12:294-1214
/branches/my_project/features/other_branch_13:583-808
/branches/my_project/features/other_branch_14:3220-3634
/branches/my_project/features/other_branch_15:4002-4385
/branches/my_project/features/other_branch_16:4175-4314
/branches/my_project/features/other_branch_17:4172-4292
/branches/my_project/features/other_branch_18:2356-2911
/branches/my_project/patches/patch_1:296-3919
/branches/my_project/patches/patch_2:825-942
/branches/my_project/patches/patch_3:1154,1222-3920
/branches/my_project/patches/patch_4:1533-1932
/branches/my_project/patches/patch_5:2538-3921
/branches/my_project/patches/patch_6:3181-3277
/branches/features/old_branch_1:55-293
/branches/features/old_branch_2:80-293
/branches/patches/old_patch_1:33-295
/trunk/my_project:4401-4525
I tried to run the checkout on the server using the file:// protocol but
it won't allow me to use it as I got the following error:
C:\Users\Administrator> C:\csvn\bin\svn co
"file://C:/csvn/data/repositories/REPO"
svn: E180001: Unable to connect to a repository at URL
'file://C:/csvn/data/repositories/REPO
svn: E180001: Unable to open an ra_local session to URL
svn: E180001: Unable to open repository
'file://C:/csvn/data/repositories/REPO'
I suspect that is is due to the fact we are using the CollabNet Subversion
Edge Server and I think the file:// protocol may be disabled by default.
I could not see any obvious settings to enable this. I will have to see
if I can get the local file protocol working and send the information when
I have it.
Many Thanks,
Stefan
On 16/09/2013 11:33, "Stefan Sperling" <st...@elego.de> wrote:
>On Mon, Sep 16, 2013 at 10:03:36AM +0000, Goor, Stefan wrote:
>> 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?
>
>We want to know why you are seeing:
>
>> Missing ranges: /trunk/my_projec:4485
>
>which lacks a trailing 't' in the path name.
>
>That's the only obviously wrong thing in your problem report.
>
>Now, to figure out where this 't' is snipped off, we want you to give
>us information that narrows down the circumstances of the problem.
>
>We'd like to see:
>
>- Output of 'svn propget svn:mergeinfo ^/trunk/my_project'
>- Output of 'svn propget svn:mergeinfo ^/branches/my_project'
>
>The above two commands are using URLs, they return server-side
>information.
>
>- Output of 'svn propget svn:mergeinfo working_copy_of_trunk_my_project'
>- Output of 'svn propget svn:mergeinfo
>working_copy_of_branches_my_project'
>
>The above two commands are using working copy paths, they return
>client-side information.
>
>Any difference (or non-difference) between these outputs will help us
>narrow down which layer of the system is introducing mergeinfo which
>lacks the trailing character of the pathname. Based on that information
>we can determine further diagnostics.
>
>If you could try the merge on the server itself, using a file:// URL to
>access the repository, we can tell whether the issue happens only if
>HTTP is involved. This is an important test since the HTTP layer
>in Subversion 1.8 is very from Subversion 1.7, see
>http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted
>
>For information about what file:// URLs are and how to use them, see
>http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.advanced.r
>eposurls
>If you don't have command shell access to the Subversion server,
>performing this test requires help from your server administrators.
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Sep 16, 2013 at 10:03:36AM +0000, Goor, Stefan wrote:
> 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?
We want to know why you are seeing:
> Missing ranges: /trunk/my_projec:4485
which lacks a trailing 't' in the path name.
That's the only obviously wrong thing in your problem report.
Now, to figure out where this 't' is snipped off, we want you to give
us information that narrows down the circumstances of the problem.
We'd like to see:
- Output of 'svn propget svn:mergeinfo ^/trunk/my_project'
- Output of 'svn propget svn:mergeinfo ^/branches/my_project'
The above two commands are using URLs, they return server-side information.
- Output of 'svn propget svn:mergeinfo working_copy_of_trunk_my_project'
- Output of 'svn propget svn:mergeinfo working_copy_of_branches_my_project'
The above two commands are using working copy paths, they return
client-side information.
Any difference (or non-difference) between these outputs will help us
narrow down which layer of the system is introducing mergeinfo which
lacks the trailing character of the pathname. Based on that information
we can determine further diagnostics.
If you could try the merge on the server itself, using a file:// URL to
access the repository, we can tell whether the issue happens only if
HTTP is involved. This is an important test since the HTTP layer
in Subversion 1.8 is very from Subversion 1.7, see
http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted
For information about what file:// URLs are and how to use them, see
http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.advanced.reposurls
If you don't have command shell access to the Subversion server,
performing this test requires help from your server administrators.
RE: SVN merge attempting to reintegrate on a merge to a branch
Posted by Andrew Reedick <An...@cbeyond.net>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: Monday, September 16, 2013 5:35 AM
> To: Andrew Reedick
> Cc: Goor, Stefan; users@subversion.apache.org
> Subject: Re: SVN merge attempting to reintegrate on a merge to a branch
>
> On Fri, Sep 13, 2013 at 04:16:17PM -0400, Andrew Reedick wrote:
> > > -----Original Message-----
> > > From: Goor, Stefan [mailto:SGoor@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:// ?
This reply is a little late (jury duty) but svn:mergeinfo was clean (no truncations) on trunk and trunk/config for ^/..., working path, and directly on the server using file:///.
Hopefully, http://svn.apache.org/r1523666 fixes the problem.
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by "Goor, Stefan" <SG...@thetasgroup.com>.
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" <st...@elego.de> wrote:
>On Fri, Sep 13, 2013 at 04:16:17PM -0400, Andrew Reedick wrote:
>> > -----Original Message-----
>> > From: Goor, Stefan [mailto:SGoor@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:// ?
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Sep 13, 2013 at 04:16:17PM -0400, Andrew Reedick wrote:
> > -----Original Message-----
> > From: Goor, Stefan [mailto:SGoor@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:// ?
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by "Goor, Stefan" <SG...@thetasgroup.com>.
Hi Andrew,
I think it's a problem in the 1.8 client. I tested doing the merge with
the same branch using a 1.6 SVN client for the checkout and the merge and
it did not encounter any issues or complain about missing revisions. This
leads me to believe that it is a bug and not just a presentation issue.
It is preventing the merge from working in the way described in the manual
and we have both encountered the same issue so I think I will raise this
issue in the bug tracker. I checked to see is there anything in there
already but I could not find anything relevant.
Thanks,
Stefan
On 13/09/2013 21:16, "Andrew Reedick" <An...@cbeyond.net> wrote:
>
>
>> -----Original Message-----
>> From: Goor, Stefan [mailto:SGoor@thetasgroup.com]
>> Sent: Friday, September 13, 2013 3:53 PM
>> To: Andrew Reedick; users@subversion.apache.org
>> Subject: Re: SVN merge attempting to reintegrate on a merge to a branch
>>
>> Hi Andrew,
>>
>> Thanks for your response. You are right, I hadn't noticed but on the
>> first line about the missing ranges the last letter of the project name
>> is missing and I had just pasted over it when I sanitized the path
>> names.
>>
>> I got around this as you suggested by using the -r 4401:HEAD option but
>> this is becoming a recurring problem for us lately. We prefer to merge
>> the trunk project to the branch in preparation of reintegrating the
>> branch to trunk but we seem to hit this issue quite a bit lately.
>>
>> 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?
>
>
RE: SVN merge attempting to reintegrate on a merge to a branch
Posted by Andrew Reedick <An...@cbeyond.net>.
> -----Original Message-----
> From: Goor, Stefan [mailto:SGoor@thetasgroup.com]
> Sent: Friday, September 13, 2013 3:53 PM
> To: Andrew Reedick; users@subversion.apache.org
> Subject: Re: SVN merge attempting to reintegrate on a merge to a branch
>
> Hi Andrew,
>
> Thanks for your response. You are right, I hadn't noticed but on the
> first line about the missing ranges the last letter of the project name
> is missing and I had just pasted over it when I sanitized the path
> names.
>
> I got around this as you suggested by using the -r 4401:HEAD option but
> this is becoming a recurring problem for us lately. We prefer to merge
> the trunk project to the branch in preparation of reintegrating the
> branch to trunk but we seem to hit this issue quite a bit lately.
>
> 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?
Re: SVN merge attempting to reintegrate on a merge to a branch
Posted by "Goor, Stefan" <SG...@thetasgroup.com>.
Hi Andrew,
Thanks for your response. You are right, I hadn't noticed but on the
first line about the missing ranges the last letter of the project name is
missing and I had just pasted over it when I sanitized the path names.
I got around this as you suggested by using the -r 4401:HEAD option but
this is becoming a recurring problem for us lately. We prefer to merge
the trunk project to the branch in preparation of reintegrating the branch
to trunk but we seem to hit this issue quite a bit lately.
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?
Many Thanks,
Stefan
On 13/09/2013 18:18, "Andrew Reedick" <An...@cbeyond.net> wrote:
>
>
>> From: Goor, Stefan [mailto:SGoor@thetasgroup.com]
>> Sent: Friday, September 13, 2013 11:40 AM
>> To: users@subversion.apache.org
>> Subject: SVN merge attempting to reintegrate on a merge to a branch
>>
>>
>> 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 $SVNROOT/trunk/my_project .
>> svn: E195016: Reintegrate can only be used if revisions 4401 through
>>4545 were previously merged from
>>https://our.svn.servername/svn/branches/my_project/features/my_project_br
>>anch to the reintegrate source, but this is not the case:
>> trunk/my_project
>> Missing ranges: /trunk/my_project:4485
>> Missing ranges:
>>/trunk/my_project:4407-4408,4431,4442-4444,4485,4524,4532-4533
>
>Since you sanitized your path names, is there any chance that the "t" in
>"my_project" is being left off on the first "missing ranges" line? E.g.
> trunk/my_project
> Missing ranges: /trunk/my_projec:4485 <--- ** Missing 't' in
>'my_project' **
> Missing ranges:
>/trunk/my_project:4407-4408,4431,4442-4444,4485,4524,4532-4533
>
>
>When I encountered this, the solution was to either merge the branch to
>trunk (svn merge ^/.../my_project_branch), or to explicitly specify the
>revision range when merging up from trunk, e.g. "svn merge -r 4401:4545
>^/trunk/my_project".
>
>
RE: SVN merge attempting to reintegrate on a merge to a branch
Posted by Andrew Reedick <An...@cbeyond.net>.
> From: Goor, Stefan [mailto:SGoor@thetasgroup.com]
> Sent: Friday, September 13, 2013 11:40 AM
> To: users@subversion.apache.org
> Subject: SVN merge attempting to reintegrate on a merge to a branch
>
>
> 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 $SVNROOT/trunk/my_project .
> svn: E195016: Reintegrate can only be used if revisions 4401 through 4545 were previously merged from https://our.svn.servername/svn/branches/my_project/features/my_project_branch to the reintegrate source, but this is not the case:
> trunk/my_project
> Missing ranges: /trunk/my_project:4485
> Missing ranges: /trunk/my_project:4407-4408,4431,4442-4444,4485,4524,4532-4533
Since you sanitized your path names, is there any chance that the "t" in "my_project" is being left off on the first "missing ranges" line? E.g.
trunk/my_project
Missing ranges: /trunk/my_projec:4485 <--- ** Missing 't' in 'my_project' **
Missing ranges: /trunk/my_project:4407-4408,4431,4442-4444,4485,4524,4532-4533
When I encountered this, the solution was to either merge the branch to trunk (svn merge ^/.../my_project_branch), or to explicitly specify the revision range when merging up from trunk, e.g. "svn merge -r 4401:4545 ^/trunk/my_project".