thanks for your email. your idea is fine, but that's not be what i
asked. perhaps there are some revisions that i may want to exclude on
purpose, either temporarily or forever. hence the email subject,
2009/4/22 Mike Meyer <mmeyer_at_lexmark.com>:
> marc gonzalez-carnicer <carnicer.lists_at_gmail.com> wrote on 04/22/2009
> 03:50:20 PM:
>> this was discussed long time ago, i've been looking for an answer
>> before posting.
>> i need to do multiple non-sequential revisions merge (cherrypicking),
>> from a "new feature" branch to the trunk. the "new feature" branch has
>> been updated with revisions from the trunk several times.
>> when the "new feature" has been finished and tested it's time to bring
>> over. for that, i need to perform the above mentioned cherrypicking,
>> which consists on a merge of multiple non-sequential revisions.
> In my opinion (<- note that - this is my opinion of best practice, others
> will certainly disagree) you're doing the last merge wrong. Instead of
> trying to cherry pick the changes you want from the feature branch, you
> should make sure that *all* the changes in the trunk have been merged to the
> feature branch, then copy the feature branch onto the trunk. The idea is
> that all the disruption from the new feature, including the work of
> integrating it into the trunk, happens on the feature branch. The final copy
> to the trunk - which is the only time the trunk will be affected - should be
> painless: check out a pristine copy of the trunk, merge the differences
> between the trunk and the feature branch into that working copy - which
> should have no conflicts since you started with the trunk, and leave the WC
> as a copy of the feature branch - then commit that.
> This works pretty painlessly in all version of svn back to 1.1, and even in
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-24 13:59:00 CEST