On Thu, Apr 9, 2009 at 11:07 AM, David Ferguson
<ferguson.david_at_gmail.com> wrote:
> As heavy users of sparse checkouts and merging, my users and I get bit by
> this confusion all the time. Users either don't understand why something
> they expected isn't getting merged in or they think they have merged
> everything but in fact they merged incompletely because of their sparse
> checkout.
>
> I would very much appreciate it if the default were changed to infinity.
>
> On Thu, Apr 9, 2009 at 10:40 AM, Paul Burba <ptburba_at_gmail.com> wrote:
>>
>> Currently (trunk_at_37129) the default depth of a merge is the depth of
>> the merge target. If the target has children that are at a deeper
>> depth then those children are not merged to.
>>
>> For example, say we have this merge target:
>>
>> branch/ (depth == immediates)
>> branch/notes/ (depth == empty)
>> branch/src/ (depth == infinity)
>> branch/README.TXT (depth N/A)
>>
>> If we merge with no depth option specified the merge will not merge
>> any applicable changes into branch/src/*.
>>
>> Several people find this a bit counter-intuitive, and I agree:
>>
>> http://svn.haxx.se/dev/archive-2009-03/0701.shtml
>>
>> This can be worked around by passing --depth=infinity to the merge
>> subcommand, but I doubt many users will realize this.
>>
>> Also, this is inconsistent with how update works. In the above
>> example if we update branch with no --depth or --set-depth option then
>> branch/src/* would get any available updates.
>>
>> I'd like to change merge's default depth to infinity. Any objections
>> or thoughts?
One unintended consequence of making this change:
Given my previous example:
branch/ (depth == immediates)
branch/notes/ (depth == empty)
branch/src/ (depth == infinity)
branch/README.TXT (depth N/A)
If we merge rN from 'trunk', and rN includes a change to
'trunk/notes/README', there will now be a tree conflict on
'branch/notes' of the 'local delete, incoming edit upon merge' flavor.
So we will trade one unexpected behavior, not merging into infinite
depth children, for potentially another unexpected behavior, trying to
merge into sparse children. The latter situation is preferable IMO
because you can't commit without addressing the tree conflicts. In
the former (i.e. current) situation you could easily commit thinking
there were no changes to your missing children when in fact there
were. I don't think this is any reason not to make the proposed
change, but wanted to throw it out there if anybody disagrees.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1629751
Received on 2009-04-10 14:13:42 CEST