hi,
2009/4/24 Mike Meyer <mmeyer_at_lexmark.com>:
>
> 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.
actually, because of the chaos caused by the multiple merge operations
triggered by my single command, before posting i had done as you
suggested : merge all the trunk into the feature branch, then merge
back, not copy (a copy / overwrite may not take care of added and
specially deleted files). then i exported both WCs and did a recursive
diff with meld to check if both branches looked identical. however,
what i did does not leave me with the peace of mind that the merge
back is correct, and i am still unsure that the final result has what
it needs to have, and does not have what is must not have.
> 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.
i can agree with your definition that when something makes your life
difficult, that is probably a bad idea to do. however, i do strongly
believe that merging back a feature branch into the trunk should be
something easy and smooth, as long as development in both branches has
been done with a minimum care.
i learned through pain that one should not merge back into the trunk
the revisions that conform the branch updates from the trunk. that's
what svnmerge.py does. so if like in my case, there is no merge
tracking info, merging back becomes manual cherrypicking, after all.
the fact that multiple revision ranges merging is performed in
multiple steps does not always allow for trouble free merging back.
that's a feature i was used to in an old, now deprecated VCS named
sccs (used by sun's teamware), that is fundamental for team
development.
/marc
> <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=1907638
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-25 11:06:58 CEST