On Fri, Aug 20, 2010 at 1:38 PM, Paul Burba <ptbu...@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): > > tr...@987562-mulitple-db>del A2\D\H\psi > > tr...@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 > > tr...@987562-mulitple-db>svn st > M A2 > !M A2\D\H\psi > > tr...@987562-mulitple-db>svn resolve -R . --accept theirs-full > > tr...@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
