"Unable to parse reversed revision range" when merging from trunk to branch
I posted this already to the TortoiseSVN users list, but I think this issue may be on the client layer and not the tortoise interface. I'm trying to catch up a branch with the changes on trunk. It seems to update the correct files, though at the end it fails with "Unable to parse reversed revision range '19634-19631'" I'm using TortoiseSVN 1.9.5 on Windows 8.1: X:\Subversion >svn --version svn, version 1.9.5 (r1770682) I looked both on trunk and the branch for odd mergeinfo. Trunk has no mergeinfo newer than the branch (the last merge to it was ages ago). I did a search for those revisions on the branch, but they don't appear reversed: X:\Subversion>svn propget svn:mergeinfo --depth=infinity | find "19631" /trunk:15014-19472,19473-19612*,19613-19614,19615-19630*,19631-19634,19635-20055* What exactly is that error message telling me, and how do I resolve it? I did a google search, but the responses I found were for svn versions from years ago, or for svndumps. I'm tempted to just copy everything over and to hack the mergeinfo manually, but I'm sure that'll cause more problems. I just tried a “Test” merge in TortoiseSVN and that completed without that error. Cheers, Jens
Re: "Unable to parse reversed revision range" when merging from trunk to branch
On Thu, Jun 29, 2017 at 3:47 PM, Jens Christian Restemeier wrote: > I posted this already to the TortoiseSVN users list, but I think this issue > may be on the client layer and not the tortoise interface. > > > > I'm trying to catch up a branch with the changes on trunk. It seems to > update the correct files, though at the end it fails with > > "Unable to parse reversed revision range '19634-19631'" > > I'm using TortoiseSVN 1.9.5 on Windows 8.1: > > X:\Subversion >svn --version > svn, version 1.9.5 (r1770682) > > I looked both on trunk and the branch for odd mergeinfo. Trunk has no > mergeinfo newer than the branch (the last merge to it was ages ago). I did a > search for those revisions on the branch, but they don't appear reversed: > > X:\Subversion>svn propget svn:mergeinfo --depth=infinity | find "19631" > > /trunk:15014-19472,19473-19612*,19613-19614,19615-19630*,19631-19634,19635-20055* > > What exactly is that error message telling me, and how do I resolve it? > > I did a google search, but the responses I found were for svn versions from > years ago, or for svndumps. > > I'm tempted to just copy everything over and to hack the mergeinfo manually, > but I'm sure that'll cause more problems. > > > > I just tried a “Test” merge in TortoiseSVN and that completed without that > error. > That's quite strange. The error message comes from this line in the source code: http://svn.apache.org/viewvc/subversion/tags/1.9.5/subversion/libsvn_subr/mergeinfo.c?view=markup#l536 I'm not familiar with that part of the code, but I can only imagine that somehow this reversed range gets processed during the merge operation. Can you reproduce this with commandline svn, and get the same error message that way? If so, can you give the exact command? I still think this reversed range is somewhere present in the svn:mergeinfo property, where it shouldn't be. -- Johan
Re: Checksum Mismatch Error on checkout, update, commit
On Tue, Jun 20, 2017 at 7:47 AM, Nishanth A wrote: > > Hi, > > Getting following errors while checkout the code. Better to copy-paste the text of the error message in your mail, instead of (or in addition of) a screenshot. Anyway, your mail lacks a lot of detail for us to be able to help you. Most importantly: which type of client, and which version are you using. Apart from that, first suggestion would be to perform an 'svnadmin verify' on the repository on the server, to make sure the repository is still valid. And: find out whether it's a problem only for a single client computer, and other users are able to checkout fine. Or whether it happens for everyone checking out the same part. -- Johan
Re: svn status merges intersected external records into single row
On Tue, Jun 13, 2017 at 3:47 PM, Andrey wrote: > Here is the batch script for the windows: > > ``` > @echo off > > set REPODIR=test_repo > set "REPOROOT=%~dp0%REPODIR%" > set "REPOURL=file:///%REPOROOT:\=/%" > set WCROOT=%REPODIR%_root > > if exist "%REPOROOT%\" rmdir /S /Q "%REPOROOT%" > if exist "%WCROOT%\" rmdir /S /Q "%WCROOT%" > > mkdir "%REPOROOT%" > svnadmin create "%REPOROOT%" > mkdir "%WCROOT%" > > svn co "%REPOURL%" "%WCROOT%" > > rem creating tree w/o externals > mkdir "%WCROOT%/dir1/dir1_subdir1" || goto :EOF > mkdir "%WCROOT%/dir1/dir1_subdir2" || goto :EOF > mkdir "%WCROOT%/dir2/dir2_subdir1" || goto :EOF > mkdir "%WCROOT%/dir2/dir2_subdir2" || goto :EOF > > svn add "%WCROOT%/*.*" || goto :EOF > > svn ci "%WCROOT%" -m "rev1" || goto :EOF > > rem update to the head > svn up "%WCROOT%" || goto :EOF > > rem creating externals > type nul > "$externals.txt" > > ( > echo.^^/dir1/dir1_subdir1 ext/dir1_subdir1 > echo.^^/dir1/dir1_subdir2 ext/dir1_subdir2 > echo.^^/dir2/dir2_subdir1 dir2_subdir1 > echo.^^/dir2/dir2_subdir2 dir2_subdir2 > ) >> "$externals.txt" > > svn pset svn:externals -F "$externals.txt" "%WCROOT%" || goto :EOF > > svn ci "%WCROOT%" -m "rev2" || goto :EOF > > rem update to the head > svn up "%WCROOT%" || goto :EOF > > rem show status > svn status "%WCROOT%" > ``` > > The output: > > ``` > Checked out revision 0. > svn: Skipping argument: E200025: 'test_repo_root/.svn' ends in a reserved > name > A test_repo_root\dir1 > A test_repo_root\dir1\dir1_subdir1 > A test_repo_root\dir1\dir1_subdir2 > A test_repo_root\dir2 > A test_repo_root\dir2\dir2_subdir1 > A test_repo_root\dir2\dir2_subdir2 > Adding test_repo_root\dir1 > Adding test_repo_root\dir1\dir1_subdir1 > Adding test_repo_root\dir1\dir1_subdir2 > Adding test_repo_root\dir2 > Adding test_repo_root\dir2\dir2_subdir1 > Adding test_repo_root\dir2\dir2_subdir2 > Committing transaction... > Committed revision 1. > Updating 'test_repo_root': > At revision 1. > property 'svn:externals' set on 'test_repo_root' > Sendingtest_repo_root > Committing transaction... > Committed revision 2. > Updating 'test_repo_root': > > Fetching external item into 'test_repo_root\ext\dir1_subdir1': > External at revision 2. > > > Fetching external item into 'test_repo_root\ext\dir1_subdir2': > External at revision 2. > > > Fetching external item into 'test_repo_root\dir2_subdir1': > External at revision 2. > > > Fetching external item into 'test_repo_root\dir2_subdir2': > External at revision 2. > > At revision 2. > X test_repo_root\dir2_subdir1 > X test_repo_root\dir2_subdir2 > X test_repo_root\ext > > Performing status on external item at 'test_repo_root\dir2_subdir1': > > Performing status on external item at 'test_repo_root\dir2_subdir2': > > Performing status on external item at 'test_repo_root\ext\dir1_subdir1': > > Performing status on external item at 'test_repo_root\ext\dir1_subdir2': > ``` > > The externals list is: > > ``` > X test_repo_root\dir2_subdir1 > X test_repo_root\dir2_subdir2 > X test_repo_root\ext > ``` > > instead of: > > ``` > X test_repo_root\dir2_subdir1 > X test_repo_root\dir2_subdir2 > X test_repo_root\ext\dir1_subdir1 > X test_repo_root\ext\dir1_subdir2 > ``` > > This forces to use `svn pget svn:externals` + `a parser` instead of `svn > status` + `a filter` in scripting to extract the records set. Hi Andrey, I tried your repro script and I'm seeing the same. However, I'm not sure whether this is a bug or not ... The 'ext' directory in your example is an unversioned "intermediate" directory. It's supported, but it's quite special (I've never used externals like that). So what you're seeing is that 'svn status' only reports one single X line for the entire "unversioned intermediate directory", even if there are multiple externals below it. Summarized, you're saying that with this svn:externals definition: ^/dir1/dir1_subdir1 ext/dir1_subdir1 ^/dir1/dir1_subdir2 ext/dir1_subdir2 (with ext being an unversioned intermediate directory) running 'svn status' only reports one X line (for 'ext') instead of a line for each external definition (like it does with other externals): X test_repo_root\ext Strangely, if you define externals into a *versioned* subdir, it's reported with two lines, as you expect: (continuing from the result of your script) [[[ svn mkdir ext2 svn ci -mm svn up # edit svn:externals property and add two more lines like the ext-ones, with ext2. svn ci -mm svn up svn st ]]] Output of 'svn st': X dir2_subdir1 X dir2_subdir2 X ext X ext2\dir1_subdir1 X ext2\dir1_subdir2 -- Johan
Re: svn status merges intersected external records into single row
Johan Corveleyn wrote on Fri, 30 Jun 2017 00:06 +0200: > Summarized, you're saying that with this svn:externals definition: > > ^/dir1/dir1_subdir1 ext/dir1_subdir1 > ^/dir1/dir1_subdir2 ext/dir1_subdir2 > > (with ext being an unversioned intermediate directory) > running 'svn status' only reports one X line (for 'ext') instead of a > line for each external definition (like it does with other externals): > > X test_repo_root\ext 'ext' is not a file external and is not the root of a directory external, so it shouldn't be printed with status 'X'; therefore this output is a bug. ... Right?
Re: "Unable to parse reversed revision range" when merging from trunk to branch
Johan Corveleyn wrote on Thu, 29 Jun 2017 22:55 +0200: > On Thu, Jun 29, 2017 at 3:47 PM, Jens Christian Restemeier > wrote: > > X:\Subversion>svn propget svn:mergeinfo --depth=infinity | find "19631" > > > > /trunk:15014-19472,19473-19612*,19613-19614,19615-19630*,19631-19634,19635-20055* > > http://svn.apache.org/viewvc/subversion/tags/1.9.5/subversion/libsvn_subr/mergeinfo.c?view=markup#l536 > > I'm not familiar with that part of the code, but I can only imagine > that somehow this reversed range gets processed during the merge > operation. ⋮ > I still think this reversed range is somewhere present in the > svn:mergeinfo property, where it shouldn't be. Unless 'svn merge' has learnt to look for svn:mergeinfo above the cwd (which appears to be a wc root in this case) or below cropped subtrees, the natural place to look for the reversed ranged would be in svn:mergeinfo of the tree being merged. (The one passed to 'svn merge' as a positional argument.)
Merging file to file requires specifying source file by its URL
I'm trying to merge trunk/CHANGES into branches/1.9.x/CHANGES. I have two separate working copies: the current directory (./) is a working copy of branches/1.9.x and ../wc-of-trunk is a working copy of /trunk. When I try the sync merge syntax with file targets, I get an error: . $ svn merge ../wc-of-trunk/CHANGES@HEAD CHANGES subversion/svn/merge-cmd.c:407, subversion/svn/merge-cmd.c:54: (apr_err=SVN_ERR_CLIENT_BAD_REVISION) svn: E195002: Invalid merge source 'CHANGES'; a working copy path can only be used with a repository revision (a number, a date, or head) . I get that error whether or not I pass the @HEAD peg revision on the source argument. If I pass -r HEAD, I get a different error: . $ svn merge -r HEAD ^/subversion/trunk/CHANGES CHANGES subversion/svn/svn.c:3097: (apr_err=SVN_ERR_CL_INSUFFICIENT_ARGS) svn: E205001: Try 'svn help merge' for more information subversion/svn/merge-cmd.c:357: (apr_err=SVN_ERR_CL_INSUFFICIENT_ARGS) svn: E205001: Second revision required . I get that error even if I change the source argument to a local path. The odd thing is that if I take the original command, and replace the source argument by its URL, it works: . $ svn merge ^/subversion/trunk/CHANGES CHANGES --- Merging r1771273 through r1800349 into 'CHANGES': UCHANGES --- Recording mergeinfo for merge of r1771273 through r1800349 into 'CHANGES': U CHANGES So: how can I do a sync merge of file targets without specifying the full URL of the source? I'm using a 1.10-dev client. Cheers, Daniel
Re: Merging file to file requires specifying source file by its URL
On 30.06.2017 06:04, Daniel Shahaf wrote: > I'm trying to merge trunk/CHANGES into branches/1.9.x/CHANGES. I have > two separate working copies: the current directory (./) is a working > copy of branches/1.9.x and ../wc-of-trunk is a working copy of /trunk. > When I try the sync merge syntax with file targets, I get an error: > . > $ svn merge ../wc-of-trunk/CHANGES@HEAD CHANGES Perhaps @WORKING? @HEAD refers to the repository, not the working copy. -- Brane
Re: svn status merges intersected external records into single row
On Fri, Jun 30, 2017 at 4:12 AM, Daniel Shahaf wrote: > Johan Corveleyn wrote on Fri, 30 Jun 2017 00:06 +0200: >> Summarized, you're saying that with this svn:externals definition: >> >> ^/dir1/dir1_subdir1 ext/dir1_subdir1 >> ^/dir1/dir1_subdir2 ext/dir1_subdir2 >> >> (with ext being an unversioned intermediate directory) >> running 'svn status' only reports one X line (for 'ext') instead of a >> line for each external definition (like it does with other externals): >> >> X test_repo_root\ext > > 'ext' is not a file external and is not the root of a directory > external, so it shouldn't be printed with status 'X'; therefore this > output is a bug. > > ... Right? Yeah, the more I think about it, the more I think it's a bug indeed. -- Johan
