Mergeinfo for skipped paths? (was: Re: Tree Conflicts and User Interface)

On Fri, Sep 12, 2008 at 02:34:32PM +0200, Stefan Sperling wrote:
> On Fri, Sep 12, 2008 at 01:57:53PM +0200, Stefan Sperling wrote:
> > There are certain types of conflicts that require an additional
> > merge to be resolved, such as when a textdelta is applied to a file
> > which is not yet present in the target branch -- the fix is to
> > *repeat* the merge with a wider revision range, this time including
> > the revision in which the file was created on the source branch.
>
> I just realised that this is wrong.
> The merge cannot simply be repeated.
>
> Because of merge tracking, the file addition would be merged,
> but the textdelta would not be merged again.
> So the final merge result would miss the textdelta,
> unless the user reapplied it manually.

On second thought, this is actually a problem with the way
we're currently recording mergeinfo. It cannot account
for failed merges due to missing paths.

Say there was a textdelta for file foo.c in revision 4,
and the file foo.c was created in revision 3.

I am merging revision 4 into a branch.

In the current implementation, revision 4 (the textdelta)
will be skipped, but mergeinfo will claim that revision 4
was merged! (See attached recipe script for reference.)

        /trunk:2,4

Instead, I'd expect explicit mergeinfo on foo.c with
revision 4 omitted:

        /trunk/foo.c:2

or even:

        /trunk/foo.c:2,!4

if such "negative mergeinfo" was feasible -- it may be easier
to record "We failed to apply revision X to path Y" rather
than determining the answer to the question "Which revisions
in the merge range could not be applied to path Y?" after
a merge of some arbitrary revision range.

A problem of course is that we can't create create mergeinfo
for foo.c if it does not yet exist in the branch's working copy :(

So before we can solve this problem, we'd probably need to store
mergeinfo somewhere else than properties...

Any idea on how we could record mergeinfo for skipped paths
in the current implementation?

XXX big ugly hack idea: Could we extend the mergeinfo
format so that parent directories can record "negative"
mergeinfo for direct children which were skipped?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org