[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [BUG] Merging to a branch with sparsely checked out files fails without error

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 24 Mar 2009 16:44:17 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.