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".
