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