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

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

From: Paul Burba <ptburba_at_gmail.com>
Date: Thu, 2 Sep 2010 14:34:02 -0400

On Fri, Aug 20, 2010 at 1:38 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Wed, Aug 18, 2010 at 7:30 AM, Daniel Shahaf <d.s_at_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.s_at_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_at_987562-mulitple-DB>del A2\D\H\psi
>
>  trunk_at_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_at_987562-mulitple-DB>svn st
>   M      A2
>  !M      A2\D\H\psi
>
>  trunk_at_987562-mulitple-DB>svn resolve -R . --accept theirs-full
>
>  trunk_at_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
Received on 2010-09-02 20:34:39 CEST

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