On Tue, May 22, 2012 at 7:31 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Mon, May 21, 2012 at 9:00 PM, Brian Neal <bgneal_at_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
Received on 2012-05-23 15:47:33 CEST