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. -- Johan