Stefan Sperling <s...@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 - d...@des.no
