interactive conflicts suppressed after choosing 'mf' or 'tf' on tree conflict
Hi All, We are seeing some unusual functionality with svn when merging trunk to a branch. The interactive conflict prompt gets suppressed if select anything other than ‘p’ for postpone on the first conflict, which is a tree conflict. We are using the following version: svn, version 1.8.3 (r1516576) compiled Sep 25 2013, 12:21:38 on x86_64-apple-darwin12.4.0 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.2.1 - handles 'http' scheme - handles 'https' scheme The first conflict we are seeing is a tree conflict and there are a number of subsequent tree and text conflicts. If we choose to postpone the tree conflict then all the subsequent prompts appear as expected: $ svn merge ^/trunk/myproject . --- Merging r7866 through r9333 into '.': U mydir1/build.properties U mydir1/build.xml … Conflict discovered when trying to add ‘mydir2/mysubdir'. An object of the same name already exists. Select: (mf) my version, (tf) their version, (p) postpone, (q) quit resolution, (h) help: p Conflict discovered in file ‘mydir3/myfile1.txt'. Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, (mc) my side of conflict, (tc) their side of conflict, (s) show all options: … Conflict discovered in file 'mydir4/myfile2.txt'. Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, (mc) my side of conflict, (tc) their side of conflict, (s) show all options: p Summary of conflicts: Text conflicts: 15 Tree conflicts: 2 However if we choose any other option than postpone on the first tree conflict then the subsequent conflict prompt are suppressed as though the —non-interactive option was used. There is also an error message at the bottom: $ svn revert -R . Reverted ‘.' … $ svn merge ^/trunk/myproject . --- Merging r7866 through r9333 into '.': U mydir1/build.properties U mydir1/build.xml … Conflict discovered when trying to add ‘mydir2/mysubdir'. An object of the same name already exists. Select: (mf) my version, (tf) their version, (p) postpone, (q) quit resolution, (h) help: mf Summary of conflicts: Text conflicts: 14 remaining (and 0 already resolved) Tree conflicts: 1 remaining (and 1 already resolved) svn: E155027: Tree conflict can only be resolved to 'working' state; ‘/myfullpath/mydir2/mysubdir' not resolved I’m guessing that the error at the bottom is probably causing the issue but should the the subsequent prompts be suppressed? Normally if I choose something invalid during the interactive conflicts it loops back to the prompt and gives me the reason the option was invalid. Should something similar happen here? Or is this expected functionality? Would it be considered a bug? Many Thanks, Stefan
Re: SVN merge attempting to reintegrate on a merge to a branch
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 andrew.reed...@cbeyond.net wrote: -Original Message- From: Goor, Stefan [mailto:sg...@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
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-,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 s...@elego.de wrote: On Fri, Sep 13, 2013 at 04:16:17PM -0400, Andrew Reedick wrote: -Original Message- From: Goor, Stefan [mailto:sg...@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
Re: SVN merge attempting to reintegrate on a merge to a branch
Hi Stefan, On 16/09/2013 12:41, Stefan Sperling s...@elego.de wrote: On Mon, Sep 16, 2013 at 11:31:09AM +, 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_branchC:\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-,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
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
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 s...@elego.de wrote: On Mon, Sep 16, 2013 at 12:06:46PM +, 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
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-,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: ^/branches/my_project/features/my_project_branch .
--- Recording mergeinfo for merge of r4443 through r 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 s...@elego.de wrote:
On Mon, Sep 16, 2013 at 11:51:30AM +, 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_branchC:\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-,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);
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=4dsMessageId=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-,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
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 andrew.reed...@cbeyond.net wrote: From: Goor, Stefan [mailto:sg...@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-,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-,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.
