You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2010/08/07 10:51:44 UTC

Re: RFC: WCNG and Issue #2915: Merge tracking and missing subtrees due to non-svn removal

Paul Burba wrote on Fri, Aug 06, 2010 at 10:30:50 -0400:
> As described in issue #2915, in 1.6 when a merge target is a missing
> subtree due to its removal by non-svn means, we try to record
> mergeinfo such that the missing subtree doesn't have (or inherit)
> mergeinfo describing the merge:
> 
> (If you already have a vague idea of how this works you can skip to
> 'You might suggest that it makes more sense' below for the RFC)
> 
> ### A file is missing in our merge target
> 
>   1.6.13-dev>svn st
>   !       A_COPY\D\H\psi
> 
> ### No initial mergeinfo
> 
>   1.6.13-dev>svn pg svn:mergeinfo -vR
> 
> ### Merge tries to apply change to missing file, but can't
> ### and reports it as skipped
> 
>   1.6.13-dev>svn merge ^^/A A_COPY -r2:4
>   --- Merging r3 through r4 into 'A_COPY':
>   U    A_COPY\D\G\rho
>   Skipped missing target: 'A_COPY\D\H\psi'
>   Summary of conflicts:
>     Skipped paths: 1
> 
> ### Merge target gets mergeinfo describing the merge
> ### performed and the missing file gets empty "override"
> ### mergeinfo so it doesn't inherit the target's mergeinfo
> 
>   1.6.13-dev>svn st
>    M      A_COPY
>   M       A_COPY\D\G\rho
>   !M      A_COPY\D\H\psi
> 
>   1.6.13-dev>svn pg svn:mergeinfo -vR
>   Properties on 'A_COPY\D\H\psi':
>     svn:mergeinfo
> 
>   Properties on 'A_COPY':
>     svn:mergeinfo
>       /A:3-4
> 
> If the missing subtree was a directory we obviously can't set its
> properties, so we treat this as a tree conflict:
> 

When I read your "if you already know how it works", I expected that here
we'd set non-inheritable mergeinfo on the parent of the missing dir (and
then set normal mergeinfo on that dir's siblings).

Perhaps there's a very good reason we don't do that --- I'm completely
unacquainted with these mergeinfo subtleties --- but I'm just repeating what
my intuition said...

>   1.6.13-dev>svn st
>   !       A_COPY\D\H
> 
>   1.6.13-dev>svn merge ^^/A A_COPY -r2:4
>   --- Merging r3 through r4 into 'A_COPY':
>   U    A_COPY\D\G\rho
>      C A_COPY\D\H
>   Summary of conflicts:
>     Tree conflicts: 1
> 
>   1.6.13-dev>svn st
>    M      A_COPY
>   M       A_COPY\D\G\rho
>   !     C A_COPY\D\H
>         >   local delete, incoming edit upon merge
> 
> ~~~~~

Re: RFC: WCNG and Issue #2915: Merge tracking and missing subtrees due to non-svn removal

Posted by Paul Burba <pt...@gmail.com>.
On Sat, Aug 7, 2010 at 6:51 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Paul Burba wrote on Fri, Aug 06, 2010 at 10:30:50 -0400:
>> As described in issue #2915, in 1.6 when a merge target is a missing
>> subtree due to its removal by non-svn means, we try to record
>> mergeinfo such that the missing subtree doesn't have (or inherit)
>> mergeinfo describing the merge:
>>
>> (If you already have a vague idea of how this works you can skip to
>> 'You might suggest that it makes more sense' below for the RFC)
>>
>> ### A file is missing in our merge target
>>
>>   1.6.13-dev>svn st
>>   !       A_COPY\D\H\psi
>>
>> ### No initial mergeinfo
>>
>>   1.6.13-dev>svn pg svn:mergeinfo -vR
>>
>> ### Merge tries to apply change to missing file, but can't
>> ### and reports it as skipped
>>
>>   1.6.13-dev>svn merge ^^/A A_COPY -r2:4
>>   --- Merging r3 through r4 into 'A_COPY':
>>   U    A_COPY\D\G\rho
>>   Skipped missing target: 'A_COPY\D\H\psi'
>>   Summary of conflicts:
>>     Skipped paths: 1
>>
>> ### Merge target gets mergeinfo describing the merge
>> ### performed and the missing file gets empty "override"
>> ### mergeinfo so it doesn't inherit the target's mergeinfo
>>
>>   1.6.13-dev>svn st
>>    M      A_COPY
>>   M       A_COPY\D\G\rho
>>   !M      A_COPY\D\H\psi
>>
>>   1.6.13-dev>svn pg svn:mergeinfo -vR
>>   Properties on 'A_COPY\D\H\psi':
>>     svn:mergeinfo
>>
>>   Properties on 'A_COPY':
>>     svn:mergeinfo
>>       /A:3-4
>>
>> If the missing subtree was a directory we obviously can't set its
>> properties, so we treat this as a tree conflict:
>>
>
> When I read your "if you already know how it works", I expected that here
> we'd set non-inheritable mergeinfo on the parent of the missing dir (and
> then set normal mergeinfo on that dir's siblings).
>
> Perhaps there's a very good reason we don't do that --- I'm completely
> unacquainted with these mergeinfo subtleties --- but I'm just repeating what
> my intuition said...

Hi Daniel,

Yours is a not unreasonable assumption given how we handle other types
of 'missing' subtrees during a merge.   Nothing was done to fix this
in 1.5 simply because it was a low priority problem
(http://subversion.tigris.org/issues/show_bug.cgi?id=2915#desc2).

That 1.6 calls this a tree conflict due to the 'local delete' of of
the directory is also bit odd since I suspect most of us would
consider a 'local delete' as something due to 'svn delete' or perhaps
a shallow working copy, rather than an OS-level removal of the
directory.

Regardless, with wcng's single DB we now have the opportunity to fix
this in a very satisfactory way.  Did you have any opinions on my two
suggested solutions?  Or perhaps a third option occurred to you?

Paul


>>   1.6.13-dev>svn st
>>   !       A_COPY\D\H
>>
>>   1.6.13-dev>svn merge ^^/A A_COPY -r2:4
>>   --- Merging r3 through r4 into 'A_COPY':
>>   U    A_COPY\D\G\rho
>>      C A_COPY\D\H
>>   Summary of conflicts:
>>     Tree conflicts: 1
>>
>>   1.6.13-dev>svn st
>>    M      A_COPY
>>   M       A_COPY\D\G\rho
>>   !     C A_COPY\D\H
>>         >   local delete, incoming edit upon merge
>>
>> ~~~~~
>