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
