[Svnmerge] [PATCH] fix bugs and tests from r22788

[lsuvkne at onemodel.org]

>>> On Sat, Jul 7, 2007 at  2:51 pm, in message <468FFCB7.2070409 at develer.com>,
Giovanni Bajo <rasky at develer.com> wrote: 
> On 07/07/2007 21.53, Dustin J. Mitchell wrote:
>> On Sat, Jun 30, 2007 at 01:20:24PM ‑0600, lsuvkne at onemodel.org wrote:
>>> The problem is that r22788 is initializing to the wrong revision number.  If
>>> we copy, say, branch from trunk (becoming, respectively, the merge source 
> and
>>> merge target‑‑I prefer the names source and target in the code, since the
>>> merges could go in any direction), then there are 2 revision numbers of
>>> interest:
>>>    1) the particular revision number of the trunk (merge target) from which
>>>    the branch (merge source) was copied
>>>    2) and the revion number in which the copy was committed to create the
>>>    branch (merge source)
>>> #1 above is the one that r22788 uses. This causes problems I'll demonstrate
>>> below. #2 is the one that we want to use for initializing a branch in *this
>>> scenario*.  We want to use #2 because the changes that occur between 
> revisions
>>> #1 and #2 are not of interest (we are trying to merge in changes that 
> occurred
>>> ON the branch, which didn't exist before #2).
>>>
>>> Note however, that this situation reverses if the trunk becomes the merge
>>> source, and the branch becomes the merge target (i.e., one is merging into a
>>> branch from trunk, to stay synchronized with the changes on trunk).  In that
>>> case we do want to initialize to revision #1 above.  I'll try to handle this
>>> in a subsequent patch.
>>>
>>> (Another scenario is the one that svnmerge already handled automatically: 
> when
>>> neither the merge source nor target is a copy of the other. In this case it
>>> inits svnmerge on the target to the latest revision of the merge source,
>>> saying in effect, "everything has been merged, so start tracking from right
>>> now).
>> 
>> This is a *great* explanation of the problem!  Great enough that I think
>> it's worth quoting in full :)
> 
> I'm missing too much history to understand it fully. I have a main question: 
> 
> was the "svnmerge.py init" behaviour changed? If not, why we need to update 
> the tests?

Yes.  The test suite for svnmerge.py hasn't passed since r23052. That one is 
an easy fix--we just needed to add "--force" to some tests since it was added
to some commands.  Then r22788 broke more tests because it changed the
behavior of "init", intending (I believe) to make the revision list automatic if one 
branch was copied from the other.  But as I explain above I think it was just not 
thought through then as well as now with the benefit of hindsight, hence my patch
(to both svnmerge.py and the tests, since I attempted to fix the behavior as
checked by several tests--now improved so I changed the tests to match).

-Luke