Re: Tree conflict resolution considered harmful

Stefan Sperling <stsp_at_elego.de> writes:
> A tree conflict occurs because config.h.in was deleted from head in
> r294466: [...] However, config.h.in still exists on the
> vendor-branch, and during the merge of r338344 we get an edit for this
> file:

Correct, same goes for all the .0 files (which are prerendered versions
of the man pages). I removed them from the target branch because they
are not needed and are sometimes overwritten during the porting process,
resulting in further text conflicts down the line.

> And now starts our first bit of trouble. There is no youngest common
> ancestor: [...] This is because FreeBSD's history did not actually
> follow the vendor-branch pattern with openssh, at least not in the way
> SVN would expect this pattern. This goes back all the way to CVS
> days, so the commits below where generated by cvs2svn.

We didn't have a consistent procedure for vendor imports back then, and
CVS is pretty shit at branches. I vaguely recall that OpenSSH actually
had two separate vendor branches in CVS and required manual intervention
during the transition to Subversion.

> Obviously, what we want to resolver to do here is to discard
> the incoming edit and mark the tree conflict as resolved.

Yes. With --accept=postpone (which I had forgotten about), I just do:

% svn resolved $(svn stat | awk '$2 == "C" { print $3 }')

> The conclusion I am drawing from this is that asking the resolver scan
> for moves unconditionally was a mistake. It is better to only do so if
> a youngest common ancestor is known since it will act as a bound for
> our search through history. [...] I've committed my fix to trunk in
> https://svn.apache.org/r1839662

Thank you very much. I really didn't expect a solution so soon!

DES

-- 
Dag-Erling Smørgrav - des_at_des.no