On Tue, Jun 29, 2010 at 11:42 AM, C. Michael Pilato <cmpil...@collab.net> wrote:
> On 06/29/2010 10:36 AM, C. Michael Pilato wrote:
>> On 06/29/2010 10:26 AM, Brandt, Servatius (External) wrote:
>>> This is an suggestion to improve the --reintegrate option to perform
>>> similar checks on a 2-URL merge as it already does when used with
>>> a 1-URL merge.
>>
>> Ahem. I think we lack this patch:
>>
>> Index: subversion/svn/merge-cmd.c
>> ===================================================================
>> --- subversion/svn/merge-cmd.c (revision 958677)
>> +++ subversion/svn/merge-cmd.c (working copy)
>> @@ -334,6 +334,11 @@
>> }
>> else
>> {
>> + if (opt_state->reintegrate)
>> + return svn_error_create(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
>> + _("Cannot specify --reintegrate "
>> + "with two URLs"));
>> +
>> err = svn_client_merge3(sourcepath1,
>> &first_range_start,
>> sourcepath2,
>>
>> I don't believe we support --reintegrate on a two-URL merge. Unfortunately,
>> the client doesn't tell you that -- it just silently falls into a
>> non-reintegrate merge codepath.
>
> I've added a check for this condition in r959004. Will propose for backport
> to 1.6.x, too.
>
> Just to be clear, Servatius, we don't support the use of the --reintegrate
> option with 2-URL merges. You've managed to point out (perhaps
> inadvertantly) that our client doesn't complain when you try to do that,
> though, so that's what I've fixed here. You might want to talk through
> (over on our users@ list) whatever scenario led you to attempt this type of
> merge: what situation merits it, what you expected to happen, etc.
Agreed, the use case here is legit: Changes on a feature branch need
to make their way to a release branch. I'm simply opposed to having
--reintegrate play a part here (plus I'm grumpy from merge
overexposure :-)
Paul
