RE: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

> -----Original Message-----
> From: Bert Huijben [mailto:bert_at_qqmail.nl]
> Sent: zaterdag 14 maart 2015 13:06
> To: 'Pete Harlan'
> Cc: 'subversion'; pburba_at_collab.net; 'Julian Foad'
> Subject: RE: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
>
> [CC-ing two Subversion developers that might have more input on this... I'm not
> a merge expert :-)]
>
> > -----Original Message-----
> > From: Pete Harlan [mailto:pchpublic88_at_gmail.com]
> > Sent: zaterdag 14 maart 2015 02:45
> > To: Bert Huijben
> > Cc: subversion
> > Subject: Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
> >
> > Thank you for your response! This may demonstrate my question more
> > clearly:
> >
> > The script I posted creates an empty trunk and a branch from it, and
> > then creates dir/file.txt in both trunk and branch separately, and
> > then merges trunk to branch, resulting in this tree conflict:
> >
> > % svn st
> > M .
> > C dir
> > > local dir obstruction, incoming dir add upon merge
> > M dir/file.txt
> > Summary of conflicts:
> > Tree conflicts: 1
> >
> > The path dir/file.txt gains an (empty) svn:mergeinfo property that
> > remains after resolving and committing the merge:
> >
> > % svn propget svn:mergeinfo -R
> > . - /trunk:2-4
> > dir/file.txt -
>
> This mergeinformation on 'dir/file' is actually a copy of what was on trunk
> before this merge started, containing everything except the merge that was
> skipped.

Looking further (after turning your test in a regression test), I think this shows another problem. The conflict is on 'dir', not really on file.

But (for legacy reasons) we somehow think that conflicting directory adds are something that we can usually just ignore (because there is no real difference between directories). So the merge of dir is somehow auto resolved, but then still conflicts via file.txt.

If file is not added because there is a conflict on 'dir' that mergeinfo should really be on 'dir' instead of 'dir/file.txt'...

Where also the tree conflict is stored.

As the merge determined that 'file.txt' in the working copy, and 'file.txt' as merged are completely different nodes, it should have never changed the unrelated 'file.txt'.

I think this partially answers your question... and shows a real problem.
(This problem is fixed in r1666690)

The problem is now how would we resolve this in the future:

We still have a tree conflict. One directory with files obstructing another directory with files...
Or as 'svn info' describes it:
[[
Tree conflict: local dir obstruction, incoming dir add upon merge
   Source left: (none) ^/trunk/dir_at_1
   Source right: (dir) ^/trunk/dir_at_4
]]

I can see three ways to resolve from this situation:
* Accept whatever is currently here, as the merged situation. (accept mine-full ?)
This should just record the merge as happened and then elide with the parent.
(I thinks this matches your expectation. But it isn't implemented yet)

* Accept that what is merged in should be kept. (accept theirs-full ?)
This should delete what is currently there. (svn rm --force dir).
Perform something like 'svn cp ^/trunk/dir_at_4 dir'
(And then record the merge as happened, by not altering any mergeinfo)
Also not implemented yet... and depending on the current working copy state possibly dangerous.

* Just delete the tree conflict, and allow the user to apply his own changes
This is what currently happens with 'accept working'.

I'm not sure what the mergeinfo behavior in this state should be. I just fixed that we at least properly record the mergeinfo on 'dir', but it is possible that not recording mergeinfo is a better option here.

With these three options for resolving I don't see a case where recording the mergeinfo makes complete sense for this particular testcase... accept for allowing the merge to continue where it stopped.

In this specific conflict that can never happen, because dir never received actual changes in either branch or trunk... But in real working copies there might be hundreds of changes on both branches.

        Bert
Received on 2015-03-14 15:46:11 CET