[svnbook] r4123 committed - * en/book/ch04-branching-and-merging.xml...

[Paul Burba]

On Fri, Oct 28, 2011 at 4:55 AM, Daniel Shahaf <d.s at daniel.shahaf.name> wrote:
> svnbook at googlecode.com wrote on Thu, Oct 27, 2011 at 20:49:21 +0000:
>> Revision: 4123
>> Author:   ptburba at gmail.com
>> Date:     Thu Oct 27 13:48:50 2011
>> Log:      * en/book/ch04-branching-and-merging.xml
>>   (svn.branchemerge.basicmerging.stayinsync): Demonstrate the new 1.7
>>    restriction on mixed-rev merges in one of the early merge examples.
>>
>>
>> http://code.google.com/p/svnbook/source/detail?r=4123
>>
>> Modified:
>>  /trunk/en/book/ch04-branching-and-merging.xml
>>
>> =======================================
>> --- /trunk/en/book/ch04-branching-and-merging.xml     Wed Oct 19 22:47:35 2011
>> +++ /trunk/en/book/ch04-branching-and-merging.xml     Thu Oct 27 13:48:50 2011
>> @@ -690,6 +690,36 @@
>>
>>        <informalexample>
>>          <screen>
>> +$ svn merge ^/calc/trunk
>> +svn: E195020: Cannot merge into mixed-revision working copy
>> [357:378]; try updating first
>> +</screen>
>> +      </informalexample>
>> +
>> +      <para>Well that was unexpected! What happened was that while
>> +        making changes to your branch over the past week you now have
>> +        a working copy that is at mixed-revisions
>> +        (see <xref linkend="svn.basic.in-action.mixedrevs"/>).  With
>> +        the release of Subversion 1.7 the merge command disables merges
>
> "merge" in <tags/>?

Hi Daniel,

I assume you mean the <command> tag?  Fixed that.

Seems that isn't the only place we are mentioning subcommands without
the <command> tag.  We also refer to subcommands as commands all over
the place.  I plan to fix those up once I confirm a few things with
cmpilato re style (i.e. do we always want to say 'subcommand' when
referring to a subcommand or can we fudge a bit and use command).

>> +        into mixed-revision working copies by default.  Without going
>> +        into too much detail, this is because of limitations in the way
>> +        merges are tracked by the svn:mergeinfo property (see the
>> +        section called
>
> s/the section called//?

Fixed.

>> +        <xref linkend="svn.branchmerge.basicmerging.mergeinfo"/>
>> +        for details).  These limitations mean that merges into
>> +        mixed-revision working copies can result in unexpected text
>> +        and tree conflicts.  The merge command option
>
> (ditto)
>
>> +        <option>--allow-mixed-revisions</option> allows you to override
>> +        this prohibition, but you should only do that if you understand
>> +        the ramifications and have a good reason for doing so.  We
>> +        don't have any reason to do so here, so we update the working
>> +        copy and then reattempt the merge.</para>
>> +
>> +      <informalexample>
>> +        <screen>
>> +$ svn up
>> +Updating '.':
>> +At revision 380.
>> +
>
> Personally I expected the update to pull in some changes.  YMMV.

Heh, I hold the exact opposite view: I'd be surprised if the update
brought in any changes.  Pretty much all of my own experiences with
that error message don't involve an operative update.

Imagine the common (IMO) use case where you are the sole person
working on a feature branch.  At some point you sync the branch with
trunk then go on making commits to the branch.  You have a mixed-rev
WC, so when you try your next sync merge you get the 'Cannot merge
into mixed-revision working copy [m:n]; try updating first' error.
You update, nothing comes down, then the merge succeeds.

Another use case, creating a backport branch: You cherry pick a
change, resolves some conflicts, commit that, then try to cherry pick
some more changes.  Again you'll get the error without updating.

Anyhow, I don't want readers to think that an inoperative update in
response to this error message is a problem.

Paul

>>  $ svn merge ^/calc/trunk
>>  --- Merging r357 through r380 into '.':
>>  U    integer.c
>>
>> _______________________________________________
>> svnbook-dev mailing list
>> svnbook-dev at red-bean.com
>> http://www.red-bean.com/mailman/listinfo/svnbook-dev
>
> _______________________________________________
> svnbook-dev mailing list
> svnbook-dev at red-bean.com
> http://www.red-bean.com/mailman/listinfo/svnbook-dev
>