marc gonzalez-carnicer <carnicer.lists_at_gmail.com> wrote on 04/25/2009
05:05:55 AM:
> 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).
Yup; that's actually what I meant. I'm used to the P4 terminology, where
copy is a special case of merge, not a seperate command. Sorry 'bout the
confusion.
> 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.
Maybe the people I work with (including me) just aren't careful enough -
the only merges that are reliably "easy and smooth" are the ones that are
"make this branch look exactly like that branch". Which is why I try to
arrange things so that's what merges to the trunk look like.
> 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.
Would that be the same SCCS that Bell Labs shipped with several versions
of Unix? Until it was displaced by the (license-free) RCS from Purdue?
Neither of which properly supporte distributed development?
<mike
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1946813
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-27 16:42:30 CEST