On Tue, Mar 24, 2009 at 4:26 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Kari Granö 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.
Mike,
Actually this is what happens today. It uses non-inheritable
mergeinfo on the target and (if you specify --depth infinity) it sets
normal inheritable mergeinfo on the children that are present.
To the larger question of the default, I think I agree with the
earlier posters, the default should be infinity. I was doing some
quick testing of your example and forgot the --depth option on the
merge and found myself thinking "what the $#&!"
Paul
> 2c. Subversion can avoid recording the merge at all.
>
> The natural follow questions involve dealing with even-less-trivial cases
> where the merge target is a hodge-podge of depths.
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1405815
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1405936
Received on 2009-03-24 21:44:35 CET