You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2010/08/18 00:06:34 UTC
Re: RFC: WCNG and Issue #2915: Merge tracking and missing subtrees
due to non-svn removal
On Thu, Aug 12, 2010 at 2:51 PM, 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:
>>
>> 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
>>
>> ~~~~~
>>
>> You might suggest that it makes more sense to simply throw an error
>> when a mergeinfo aware merge hits a missing subtree rather than
>> jumping through these hoops. I wouldn't disagree, but an even better
>> solution was suggested to me recently by Bert: Restore the missing
>> subtrees. With wcng's single DB this should be easy with
>> svn_wc_restore().
>>
>> Does anyone see a reason we should not restore missing subtrees
>> encountered during a merge?
>>
>> Assuming for a moment there is general agreement about the goodness of
>> this approach, which sounds better:
>>
>> A) Check for missing subtrees at the start of the merge and restore
>> them prior to any editor drives. This would be easy enough to do in
>> libsvn_client/merge.c:get_mergeinfo_paths() which we call at the start
>> of a merges to collect information about subtrees "interesting" from a
>> merge-tracking perspective. The drawback here is that we need to
>> detect all the missing subtrees and that means a new call to
>> svn_io_check_path/apr_stat for every path in the merge target. Since
>> 99.99%* of merges don't involve missing subtrees, we are imposing a
>> needless performance penalty on most users.
>>
>
> Agreed: stat() on every file on, say, our trunk during a merge from a
> branch, is too expensive.
>
>> B) Restore the missing subtrees on-the-fly when the svn_delta_editor_t
>> callbacks (i.e. open_directory, open_file) actually encounter a
>> missing subtree. This keeps the svn_io_check_path() calls to a
>> minimum. The drawback is that missing subtrees untouched by the
>> editor are still missing after the merge.
>>
>
> *nod*
>
>> Any preference or suggestions for a superior solution are appreciated.
>>
>
> We could treat missing files as conflicts? e.g., about the same as what
> we'd do if someone truncated the file to zero length.
>
> That way all information is present locally (so there will be no need to
> repeat the merge).
(Sorry for the tardy reply, I've been on vacation and wonderfully out
of the loop the last 4 days)
That is certainly an option, but how is it better than restoring the
missing file(s) and letting the merge complete? WCNG with a single DB
enabled allows us to do that, it seems a *much* better solution that
raising what is almost certainly a spurious conflict? No? Or am I
missing something?
Paul
Re: RFC: WCNG and Issue #2915: Merge tracking and missing subtrees
due to non-svn removal
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Aug 20, 2010 at 1:38 PM, Paul Burba <pt...@gmail.com> wrote:
> On Wed, Aug 18, 2010 at 7:30 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> Paul Burba wrote on Tue, Aug 17, 2010 at 20:06:34 -0400:
>>> On Thu, Aug 12, 2010 at 2:51 PM, 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:
>>> >>
>>> >> 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
>>> >>
>>> >> ~~~~~
>>> >>
>>> >> You might suggest that it makes more sense to simply throw an error
>>> >> when a mergeinfo aware merge hits a missing subtree rather than
>>> >> jumping through these hoops. I wouldn't disagree, but an even better
>>> >> solution was suggested to me recently by Bert: Restore the missing
>>> >> subtrees. With wcng's single DB this should be easy with
>>> >> svn_wc_restore().
>>> >>
>>> >> Does anyone see a reason we should not restore missing subtrees
>>> >> encountered during a merge?
>>> >>
>>> >> Assuming for a moment there is general agreement about the goodness of
>>> >> this approach, which sounds better:
>>> >>
>>> >> A) Check for missing subtrees at the start of the merge and restore
>>> >> them prior to any editor drives. This would be easy enough to do in
>>> >> libsvn_client/merge.c:get_mergeinfo_paths() which we call at the start
>>> >> of a merges to collect information about subtrees "interesting" from a
>>> >> merge-tracking perspective. The drawback here is that we need to
>>> >> detect all the missing subtrees and that means a new call to
>>> >> svn_io_check_path/apr_stat for every path in the merge target. Since
>>> >> 99.99%* of merges don't involve missing subtrees, we are imposing a
>>> >> needless performance penalty on most users.
>>> >>
>>> >
>>> > Agreed: stat() on every file on, say, our trunk during a merge from a
>>> > branch, is too expensive.
>>> >
>>> >> B) Restore the missing subtrees on-the-fly when the svn_delta_editor_t
>>> >> callbacks (i.e. open_directory, open_file) actually encounter a
>>> >> missing subtree. This keeps the svn_io_check_path() calls to a
>>> >> minimum. The drawback is that missing subtrees untouched by the
>>> >> editor are still missing after the merge.
>>> >>
>>> >
>>> > *nod*
>>> >
>>> >> Any preference or suggestions for a superior solution are appreciated.
>>> >>
>>> >
>>> > We could treat missing files as conflicts? e.g., about the same as what
>>> > we'd do if someone truncated the file to zero length.
>>> >
>>> > That way all information is present locally (so there will be no need to
>>> > repeat the merge).
>>>
>>> (Sorry for the tardy reply, I've been on vacation and wonderfully out
>>> of the loop the last 4 days)
>>>
>>> That is certainly an option, but how is it better than restoring the
>>> missing file(s) and letting the merge complete? WCNG with a single DB
>>> enabled allows us to do that, it seems a *much* better solution that
>>> raising what is almost certainly a spurious conflict? No? Or am I
>>> missing something?
>>>
>>
>> If we mark it as a conflict, then the user can still obtain the merged
>> result by running 'svn resolve', no?
>
> I suppose that depends on how we expect resolve to handle
> missing-via-OS-delete paths. Right now it does nothing at all (which
> is the same behavior as 1.6.12):
>
> trunk@987562-mulitple-DB>del A2\D\H\psi
>
> trunk@987562-mulitple-DB>svn merge ^^/A A2 -c3
> Skipped missing target: 'A2\D\H\psi'
> --- Recording mergeinfo for merge of r3 into 'A2':
> U A2\D\H\psi
> U A2
> Summary of conflicts:
> Skipped paths: 1
>
> trunk@987562-mulitple-DB>svn st
> M A2
> !M A2\D\H\psi
>
> trunk@987562-mulitple-DB>svn resolve -R . --accept theirs-full
>
> trunk@987562-mulitple-DB>svn st
> M A2
> !M A2\D\H\psi
>
> ~~~~~
>
> I realize now that the fundamental question is not so much "how does
> merge tracking handle OS-deleted paths?", but more generally "How does
> *Subversion* handle OS-deleted paths?" I'll spin up a new thread
> asking this more general question. I suspect some of the wcng folks
> have already given some thought to this space.
>
> Paul
>
>> i.e., "whoops, the file is missing. we don't know if you wanted that or
>> not, so we'll make you take a small effort and decide explicitly".
Wrapping up this thread for posterity...
As far as merge is concerned, in 1.7 we'll raise an error if you
attempt a merge tracking aware merge to a target which is missing
subtrees due to OS-level deletes.
See discussion http://svn.haxx.se/dev/archive-2010-08/0533.shtml and
commit http://svn.apache.org/viewvc?view=revision&revision=992042
Paul
Re: RFC: WCNG and Issue #2915: Merge tracking and missing subtrees
due to non-svn removal
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Aug 18, 2010 at 7:30 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Paul Burba wrote on Tue, Aug 17, 2010 at 20:06:34 -0400:
>> On Thu, Aug 12, 2010 at 2:51 PM, 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:
>> >>
>> >> 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
>> >>
>> >> ~~~~~
>> >>
>> >> You might suggest that it makes more sense to simply throw an error
>> >> when a mergeinfo aware merge hits a missing subtree rather than
>> >> jumping through these hoops. I wouldn't disagree, but an even better
>> >> solution was suggested to me recently by Bert: Restore the missing
>> >> subtrees. With wcng's single DB this should be easy with
>> >> svn_wc_restore().
>> >>
>> >> Does anyone see a reason we should not restore missing subtrees
>> >> encountered during a merge?
>> >>
>> >> Assuming for a moment there is general agreement about the goodness of
>> >> this approach, which sounds better:
>> >>
>> >> A) Check for missing subtrees at the start of the merge and restore
>> >> them prior to any editor drives. This would be easy enough to do in
>> >> libsvn_client/merge.c:get_mergeinfo_paths() which we call at the start
>> >> of a merges to collect information about subtrees "interesting" from a
>> >> merge-tracking perspective. The drawback here is that we need to
>> >> detect all the missing subtrees and that means a new call to
>> >> svn_io_check_path/apr_stat for every path in the merge target. Since
>> >> 99.99%* of merges don't involve missing subtrees, we are imposing a
>> >> needless performance penalty on most users.
>> >>
>> >
>> > Agreed: stat() on every file on, say, our trunk during a merge from a
>> > branch, is too expensive.
>> >
>> >> B) Restore the missing subtrees on-the-fly when the svn_delta_editor_t
>> >> callbacks (i.e. open_directory, open_file) actually encounter a
>> >> missing subtree. This keeps the svn_io_check_path() calls to a
>> >> minimum. The drawback is that missing subtrees untouched by the
>> >> editor are still missing after the merge.
>> >>
>> >
>> > *nod*
>> >
>> >> Any preference or suggestions for a superior solution are appreciated.
>> >>
>> >
>> > We could treat missing files as conflicts? e.g., about the same as what
>> > we'd do if someone truncated the file to zero length.
>> >
>> > That way all information is present locally (so there will be no need to
>> > repeat the merge).
>>
>> (Sorry for the tardy reply, I've been on vacation and wonderfully out
>> of the loop the last 4 days)
>>
>> That is certainly an option, but how is it better than restoring the
>> missing file(s) and letting the merge complete? WCNG with a single DB
>> enabled allows us to do that, it seems a *much* better solution that
>> raising what is almost certainly a spurious conflict? No? Or am I
>> missing something?
>>
>
> If we mark it as a conflict, then the user can still obtain the merged
> result by running 'svn resolve', no?
I suppose that depends on how we expect resolve to handle
missing-via-OS-delete paths. Right now it does nothing at all (which
is the same behavior as 1.6.12):
trunk@987562-mulitple-DB>del A2\D\H\psi
trunk@987562-mulitple-DB>svn merge ^^/A A2 -c3
Skipped missing target: 'A2\D\H\psi'
--- Recording mergeinfo for merge of r3 into 'A2':
U A2\D\H\psi
U A2
Summary of conflicts:
Skipped paths: 1
trunk@987562-mulitple-DB>svn st
M A2
!M A2\D\H\psi
trunk@987562-mulitple-DB>svn resolve -R . --accept theirs-full
trunk@987562-mulitple-DB>svn st
M A2
!M A2\D\H\psi
~~~~~
I realize now that the fundamental question is not so much "how does
merge tracking handle OS-deleted paths?", but more generally "How does
*Subversion* handle OS-deleted paths?" I'll spin up a new thread
asking this more general question. I suspect some of the wcng folks
have already given some thought to this space.
Paul
> i.e., "whoops, the file is missing. we don't know if you wanted that or
> not, so we'll make you take a small effort and decide explicitly".
Re: RFC: WCNG and Issue #2915: Merge tracking and missing subtrees
due to non-svn removal
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Paul Burba wrote on Tue, Aug 17, 2010 at 20:06:34 -0400:
> On Thu, Aug 12, 2010 at 2:51 PM, 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:
> >>
> >> 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
> >>
> >> ~~~~~
> >>
> >> You might suggest that it makes more sense to simply throw an error
> >> when a mergeinfo aware merge hits a missing subtree rather than
> >> jumping through these hoops. I wouldn't disagree, but an even better
> >> solution was suggested to me recently by Bert: Restore the missing
> >> subtrees. With wcng's single DB this should be easy with
> >> svn_wc_restore().
> >>
> >> Does anyone see a reason we should not restore missing subtrees
> >> encountered during a merge?
> >>
> >> Assuming for a moment there is general agreement about the goodness of
> >> this approach, which sounds better:
> >>
> >> A) Check for missing subtrees at the start of the merge and restore
> >> them prior to any editor drives. This would be easy enough to do in
> >> libsvn_client/merge.c:get_mergeinfo_paths() which we call at the start
> >> of a merges to collect information about subtrees "interesting" from a
> >> merge-tracking perspective. The drawback here is that we need to
> >> detect all the missing subtrees and that means a new call to
> >> svn_io_check_path/apr_stat for every path in the merge target. Since
> >> 99.99%* of merges don't involve missing subtrees, we are imposing a
> >> needless performance penalty on most users.
> >>
> >
> > Agreed: stat() on every file on, say, our trunk during a merge from a
> > branch, is too expensive.
> >
> >> B) Restore the missing subtrees on-the-fly when the svn_delta_editor_t
> >> callbacks (i.e. open_directory, open_file) actually encounter a
> >> missing subtree. This keeps the svn_io_check_path() calls to a
> >> minimum. The drawback is that missing subtrees untouched by the
> >> editor are still missing after the merge.
> >>
> >
> > *nod*
> >
> >> Any preference or suggestions for a superior solution are appreciated.
> >>
> >
> > We could treat missing files as conflicts? e.g., about the same as what
> > we'd do if someone truncated the file to zero length.
> >
> > That way all information is present locally (so there will be no need to
> > repeat the merge).
>
> (Sorry for the tardy reply, I've been on vacation and wonderfully out
> of the loop the last 4 days)
>
> That is certainly an option, but how is it better than restoring the
> missing file(s) and letting the merge complete? WCNG with a single DB
> enabled allows us to do that, it seems a *much* better solution that
> raising what is almost certainly a spurious conflict? No? Or am I
> missing something?
>
If we mark it as a conflict, then the user can still obtain the merged
result by running 'svn resolve', no?
i.e., "whoops, the file is missing. we don't know if you wanted that or
not, so we'll make you take a small effort and decide explicitly".
> Paul
Re: RFC: WCNG and Issue #2915: Merge tracking and missing subtrees
due to non-svn removal
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Paul Burba wrote on Tue, Aug 17, 2010 at 20:06:34 -0400:
> On Thu, Aug 12, 2010 at 2:51 PM, 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:
> >>
> >> 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
> >>
> >> ~~~~~
> >>
> >> You might suggest that it makes more sense to simply throw an error
> >> when a mergeinfo aware merge hits a missing subtree rather than
> >> jumping through these hoops. I wouldn't disagree, but an even better
> >> solution was suggested to me recently by Bert: Restore the missing
> >> subtrees. With wcng's single DB this should be easy with
> >> svn_wc_restore().
> >>
> >> Does anyone see a reason we should not restore missing subtrees
> >> encountered during a merge?
> >>
> >> Assuming for a moment there is general agreement about the goodness of
> >> this approach, which sounds better:
> >>
> >> A) Check for missing subtrees at the start of the merge and restore
> >> them prior to any editor drives. This would be easy enough to do in
> >> libsvn_client/merge.c:get_mergeinfo_paths() which we call at the start
> >> of a merges to collect information about subtrees "interesting" from a
> >> merge-tracking perspective. The drawback here is that we need to
> >> detect all the missing subtrees and that means a new call to
> >> svn_io_check_path/apr_stat for every path in the merge target. Since
> >> 99.99%* of merges don't involve missing subtrees, we are imposing a
> >> needless performance penalty on most users.
> >>
> >
> > Agreed: stat() on every file on, say, our trunk during a merge from a
> > branch, is too expensive.
> >
> >> B) Restore the missing subtrees on-the-fly when the svn_delta_editor_t
> >> callbacks (i.e. open_directory, open_file) actually encounter a
> >> missing subtree. This keeps the svn_io_check_path() calls to a
> >> minimum. The drawback is that missing subtrees untouched by the
> >> editor are still missing after the merge.
> >>
> >
> > *nod*
> >
> >> Any preference or suggestions for a superior solution are appreciated.
> >>
> >
> > We could treat missing files as conflicts? e.g., about the same as what
> > we'd do if someone truncated the file to zero length.
> >
> > That way all information is present locally (so there will be no need to
> > repeat the merge).
>
> (Sorry for the tardy reply, I've been on vacation and wonderfully out
> of the loop the last 4 days)
>
> That is certainly an option, but how is it better than restoring the
> missing file(s) and letting the merge complete? WCNG with a single DB
> enabled allows us to do that, it seems a *much* better solution that
> raising what is almost certainly a spurious conflict? No? Or am I
> missing something?
>
If we mark it as a conflict, then the user can still obtain the merged
result by running 'svn resolve', no?
i.e., "whoops, the file is missing. we don't know if you wanted that or
not, so we'll make you take a small effort and decide explicitly".
> Paul