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.
This is just a guess, but I think someone had the same concerns when
the current behavior was added. However, see below ....
> 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.
>
> 2c. Subversion can avoid recording the merge at all.
This all had to be dealt with prior to 1.5 final release. 2b is the
option that was used, along with the non-inheritable mergeinfo syntax.
I believe there is a section on this in Paul Burba's mergeinfo
manifesto:
http://www.collab.net/community/subversion/articles/merge-info.html
I personally think it ought to behave like --depth=infinity by default.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1405902
Received on 2009-03-24 21:40:14 CET