On Thu, Apr 29, 2010 at 6:45 PM, Joël Conraud <jconr...@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.
