Paul, I draw your attention to the log message of my r27412 commit:
-----------------------------------------------------------------------
In a nutshell, rework the changes made in r27133 by moving the
iteration over revision ranges to just inside the
svn_client_merge_peg3 API.
The unfortunately reality is that this meant rolling this file back to
r27132 and cherry-picking changes I wanted to re-apply from after that
point, then reworking the basic notion of r27133. This is for
correctness -- having the main worker functions accept two URLs and
range of revisions makes it extremely different for those worker
functions to deal with merges from sources which suffered location
changes (renames) somewhere between the first and last revisions
merged.
NOTE: r27133 seems to have actually been about two different changes.
One of them was the change of the public merge API to accept a
revision range list instead of just a pair of revisions -- that's what
I meant to rework. The second change is something to do with talking
about 3-way-merges instead of rollbacks. I don't know why the two
changes had to be bundled. And I don't why the fact that I reverted
both changes and then reworked only the first hasn't caused the test
suite to fail at all. And I'm sad to say that I didn't even realize
there was this dual change thing going on until I started composing
this log message just prior to commit. Something tells me that second
change will need to be remade, but I'm going to defer that until
another commit.
...
-----------------------------------------------------------------------
I can't think of any reason why the API change (to support lists of ranges)
would have itself necessitated the is_rollback -> is_three_way_merge change.
Are they, in fact, distinct changes that happened to be committed at the
same time? If so, would you a) explain to me the gist of the change so I
can try to remake it, b) tell me how to test whatever it is that this change
is supposed to be testing, and c) don't combine distinct changes like that
in the future. :-)
Thanks, man.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Oct 26 10:27:52 2007