RE: SVN merge attempting to reintegrate on a merge to a branch
> -Original Message- > From: Stefan Sperling [mailto:s...@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: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: 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
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" 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_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-,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
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" 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
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
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_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-,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
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, On 16/09/2013 12:41, "Stefan Sperling" 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_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-,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
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. > 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
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_proj
Re: SVN merge attempting to reintegrate on a merge to a branch
On Mon, Sep 16, 2013 at 10:03:36AM +, 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
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/ and branches in $SVNROOT/svn/branches//features/ 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" 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: http://svn.haxx.se/u
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: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: > 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
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" 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
> -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 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" 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". > >
RE: SVN merge attempting to reintegrate on a merge to a branch
> 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_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 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".