I think you are right, Johan. I just found this post:
Specifically these lines:
>> Problems? I can't see how it would *ever* work. Reintegrate was
>> never intended to support the use case where you had a shallow branch
>> working copy. Keep in mind that --reintegrate is simply a shortcut
>> for a 2-URL merge along with some safety checks
As a test, I decided to use the TortoiseSVN (2-URL) "Merge two
different trees" merge wizard (instead of reintegrate) to merge
into the trunk, and it works. I don't get the errors described
in my original post. Now that could mean the "safely checks"
are not being performed that reintegrate normally performs but
in my case, that is good enough.
> Just one more thought: if you build a sparse working copy of trunk
> that is sparse in the same way as the branch working copy (in which
merged), would you be able to reintegrate into that?
Reintegrate option forces the target working copy to be fully
recursive. So it is not possible to test that case.
At this point, I think I have a good workaround unless I'm told
otherwise by this community. However, given that sparse working-
copies are supported, it would be nice to know definitively
if sparse working-copies should simply not be used as merge
targets (regardless of merge direction).
From: Johan Corveleyn <jcorvel_at_gmail.com>
To: Manny DaSilva <manny390_at_yahoo.com>
Sent: Fri, March 12, 2010 3:50:54 PM
Subject: Re: unable to reintegrate branch
On Fri, Mar 12, 2010 at 6:53 PM, Manny DaSilva <manny390_at_yahoo.com> wrote:
> I read article in detail:
> and now I think I know why the X/A mergeinfo has asterisk
> (/trunk/A:199-202*). Folder X/A has additional sub-folders, other
> than 1,2,3 and those sub-folders, for example X/A/4, are not
> available in the sparse working copy. OK, this makes sense.
> I tried a new test. I used a fresh copy of trunk as
> branches/Z and just used the command-line. I followed the steps
> outlined in the article section "Mergeinfo Inheritance and
> Non-Inheritable Ranges".
> The results are the same as before. As described in my first post,
> the reintegrate simply will not work .
It seems reintegrate indeed doesn't cope well with non-inheritable
mergeinfo, as you describe (non-inheritable mergeinfo by itself is not
really a problem, as long as you don't reintegrate (like with a
release branch or something like that)).
I can't judge whether this problem is a bug, or expected/intended
behavior. Maybe someone else can comment?
Just one more thought: if you build a sparse working copy of trunk
that is sparse in the same way as the branch working copy (in which
you merged), would you be able to reintegrate into that?
Received on 2010-03-12 22:37:52 CET