On Tue, May 22, 2012 at 7:31 AM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Mon, May 21, 2012 at 9:00 PM, Brian Neal <bgn...@gmail.com> wrote: > [ ... ] >> I was able to reproduce the issue, please see the attached >> sparse-merge.txt and I captured the output and error that I see in the >> attached file out.txt. (Note that I had to rename sparse-merge.bat to >> sparse-merge.txt before Gmail would send it). >> >> I am using SVN 1.7.4 on Windows XP. >> >> The high level description of what is going on in the script is: >> >> 1. Create a repo using your sample greek tree. >> 2. Make a sparse working copy of trunk, omitting the A\B directory (trunk_wc) >> 3. Copy trunk to a feature branch. >> 4. Make a sparse working copy of the feature branch (omitting A\B -- >> branch_wc) >> 5. Make a full working copy of trunk (trunk_b_wc). >> 6. Now change files in all three working copies and commit (but don't >> create conflicts). In particular, in trunk_b_wc, change a file under >> A\B. >> 7. Merge trunk to the feature branch. >> 8. Reintegrate merge the feature branch back to trunk. >> 9. Observe that the merge fails, presumably because the changes to A\B >> never made it to the feature branch. > > Ah ok, I see. It fails with: > > svn: E195016: Reintegrate can only be used if revisions 2 through 6 > were previously merged from file:///C:/Temp/svn-test > /repos/trunk to the reintegrate source, but this is not the case: > branches/feature/A > Missing ranges: /trunk/A:4 > > where revision 4 is the revision on trunk which affected A\B, which > was missing (excluded by sparseness) from the branch-wc which you used > to do the sync merge. > > I believe that this is normal behavior then, with the current > functionality of svn: revision 4 is indeed not synced, and the branch > must be synced completely (there must not be any gaps) for it to be > reintegratable. > > OTOH, you could argue that --reintegrate should just work in this > case, similar to the normal sync merge, by only looking at the parts > that are present in the working copy (and using non-inheritable > mergeinfo to mark the parts where the (reintegrate) merge was not > performed in full). Hmmm, otherwise you'd almost always need full > working copies to perform the merges, even if you're fine with only > merging (and reintegrating) some parts ... > > I'm not really an expert on the merge logic and tracking, but I think > this would be a useful enhancement (unless someone contradicts me > here). So I'd say: please file an issue.
I have filed issue #4187: http://subversion.tigris.org/issues/show_bug.cgi?id=4187 Thanks for looking the issue over Johan. Regards, -BN
