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.
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
Received on 2009-03-24 21:26:35 CET