On Tue, Mar 24, 2009 at 4:26 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> On Tue, 24 Mar 2009 13:07:01 -0400 Paul Burba <ptburba_at_gmail.com> wrote:
>>>> Just add --depth=infinity to your merge command and it works fine.
>>>> This is the expected behavior. Â I am not exactly sure why, but it
>>>> has been explained before on this list.
>>
>>> I recall that too, but can't find it. Anyhow, the way it works is:
>>> "The default depth of a merge is the same as the merge target."
>>> For example, if you don't specify a --depth and merge into directory
>>> that was checked out at depth=immediates, then the merge will proceed
>>> as if you specified --depth immediates. It won't matter if some of
>>> the target's children are themselves checked out a a greater depth.
>>
> This default is a bit surprising, if you ask me. If I have a sparse
>> working copy, why would I want to limit merge depth to the sparse root
>> of the merge target? I can't come up with any use case.
> I think there are technical challenges here that might have come into play, namely around merge tracking.
> Say in my repository's trunk, I have the following directories: "src", "doc", "testdata". Now let's say I've sparsely checked out my trunk > without the "testdata" directory:
>
> /trunk
> /trunk/src
> /trunk/doc
>
> One day, I need to merge some changes from a branch (/branches/feature), so I issue some inspired merge command.
> What if, in the set of revisions I wish to merge, there are changes inside of /branches/feature/testdata?
> There are some options:
>
> 1. Subversion can fail the merge immediately with a big "Sorry, I can't deal with that" error. This might be feasible today -- I'm not sure.
>
> 2. Subversion can attempt the merge anyway, printing "Skipped" messages for all the paths it wanted to modify as part of the merge,
> but couldn't. (Does this cause tree conflicts in 1.6-era code? I'm not sure.)
>
> 2a. Subversion can record in /trunk the merge of /branches/feature. But that's not really true, because it didn't merge all the changes.
> And because of the storage model for mergeinfo, the only place to record the fact that /trunk/testdata didn't get the merged changes is
> on /trunk/testdata, which isn't available for said recording by virtue of not being present in the working copy.
>
> 2b. Subversion can record the merge on every present sibling of /trunk/testdata -- /trunk/src and /trunk/doc, in this case.
As others have pointed out, this happens currently when you specify "--depth=infinity". Just having this as the default behavior would already be much better.
However, this leads to another, unrelated problem: merges into sparse working copies invariably produce subtree mergeinfo, which makes it hard to reason about the performed merges and can cause problems with "merge --reintegrate". I find myself manually fixing svn:mergeinfo after such merges, which is a bit tedious. I guess there's no way around that.
Kari.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1406495
Received on 2009-03-25 01:11:53 CET