Re: Cherry-picking merges

 On Thu, Apr 29, 2010 at 6:45 PM, Joël Conraud <jconraud_at_gmail.com> wrote:

> Like yourself, I initially though that it would be able to deal with this,
>> but it doesn't seem to (and there is probably a very good reason why it
>> can't).
>>
>
> I would be interested in knowing this "very good reason why it can't". I'm
> not questioning its validity, I'm confident this good reason is a good
> reason, but as I was surprised too by this behavior, if someone could give
> an explanation? I would be very interested.
>

After thinking more about it, I believe it's because a revision can contain
more than just the merge.

For example, if I merge r10 from into a branch, I don't have to commit just
that merge. I can have modifications in my working copy, merge, make more
modifications, and commit in r11. The svn:mergeinfo will attest that r10
from trunk has been merged in this revision, but it doesn't mean that r11 on
the branch is the logical equivalent of r10 on the trunk.

I think that best practices suggest that doing things in this manner is a
bad idea, and should be discouraged. A revision that contains svn:mergeinfo
changes should only contain the file and structure changes logically
equivalent to the revisions that have been merged.

Cheers,
Daniel B.
Received on 2010-04-30 06:49:27 CEST