[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Reintegrate merging with sparse checkouts

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 22 May 2012 14:31:58 +0200

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.

-- 
Johan
Received on 2012-05-22 14:32:51 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.