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.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
Received on 2010-08-18 16:32:52 CEST