[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Cherry-picking merges

From: Greg Troxel <gdt_at_ir.bbn.com>
Date: Fri, 30 Apr 2010 08:52:51 -0400

Daniel Becroft <djcbecroft_at_gmail.com> writes:

> 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.

The problem is that you have to commit on two branches at once. The
workflow is (very roughly):

  go onto merge target branch
  svn merge source branch
  svn commit => making C

  switch to source branch
  svn merge -c $C --record-only target-branch
  svn commit

We ended up writing scripts to do both of these things, which worked
because we had a structured repository.

A better fix would be to have commit C be marked as merge-from-source in
some sort of commit property and to have merge to a branch omit
changesets that are being merged back to that branch. But this has to
be carried along so when you merge from A to B to C and merge C back to
A you don't redo the A commits. So the bookkeeping is hard, but I think
that's what it takes. Implementing this might or might not be easier
than training everyone how to use Git :-)

> 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.

Absolutely. This isn't a "clean changeset" and is madness; everyone
should prohibit it.

  • application/pgp-signature attachment: stored
Received on 2010-04-30 14:53:25 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.