marc gonzalez-carnicer <carnicer.lists_at_gmail.com> wrote on 04/24/2009
07:57:57 AM:
> hi Mike,
>
> 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,
> "cherrypicking".
You're right, it doesn't answer the question you asked; I saw that that
had already been answered (you weren't doing anything wrong, that's the
way SVN works), and was trying to offer a better solution to your problem.
Even in the changed case, the principles still apply: create a branch that
looks like you want the trunk to look off the trunk so as to minimize
disruption of ongoing work, and copy that to the trunk. So you'd either
revert the revisions you want left out on the feature branch, or create a
new branch to do this on, and then copy that to the trunk. It's not clear
that either of these will avoid whatever issues you're trying to avoid,
though.
Subversion is one of the more popular free SCM systems because it supports
most reasonable practices well. When you find it making your life
difficult, there's a fair chance that what you're trying to do is a bad
idea. Not always, but it's worth checking. In this case, it is.
Cherrypicking changes is pretty much universally regarded as a bad idea.
Having worked for over a year with a client whose idea of development was
"specify the feature set we want in the next revision, and then when it's
ready for delivery pick the subset we actually want", I know from painfull
experience why cherrypicking is regarded that way.
<mike
> 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:
> >
> >> hi,
> >>
> >> 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
> > CVS.
> >
> > <mike
> >
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1892779
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-24 16:00:03 CEST