I think you are right, Johan. I just found this post: http://svn.haxx.se/dev/archive-2009-03/0752.shtml 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 > you 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). Manny ________________________________ From: Johan Corveleyn <jcor...@gmail.com> To: Manny DaSilva <manny...@yahoo.com> Cc: users@subversion.apache.org 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 <manny...@yahoo.com> wrote: > I read article in detail: > http://www.collab.net/community/subversion/articles/merge-info.html > 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? Johan
