You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by marc gonzalez-carnicer <ca...@gmail.com> on 2009/04/22 19:50:20 UTC
Re: Cherrypicking Non-Sequential Revisions
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.
for reference, i am using svn 1.5.1 on the client and svn 1.3.2 on the
server side. i am not using mergeinfo, i can't yet.
the syntax for that appears to be obvious, since examples of it
neither appear on the svnbook nor on the built-in help. finally, i end
up with a command like that :
$ svn merge \
-r 2471:2473 -r 2477:2479 -r 2484:2485 -r 2486:2491 \
-r 2492:2493 -r 2494:2496 -r 2505:2506 -r 2578:2586 \
-r 2596:2600 -r 2607:2610 -r 2611:2612 -r 2621:2624 \
-r 2626:2630 -r 2667:2668 \
svn://srv-peat-svn/home/svn/8568/branches/code.Lane.LNT .
this variant seems to be possible too
$ svn merge -c 2472,2473,2478,2479,2495,2487,2488,2489,2490,2491 \
svn://srv-peat-svn/home/svn/8568/branches/code.Lane.LNT .
to my surprise, neither command does NOT perform a unique merge
operation, and instead, as many merges as revision ranges specified.
this causes that if a file has been modified in more that one revision
group, it is merged more than once. if there are conflicts, the
situation becomes scary, and the WC a mess.
i was expecting svn merge to behave as the good old svnmerge.py
script, now forgotten by many.
am i doing something wrong or is it that svn merge can't perform these
multiple revision merge in just one try? if it is the latter case, i'd
appreciate confirmation about it.
2008/9/3 Daniel Becroft <Da...@supercorp.com.au>
>
> Ah, thanks Mark. I was looking in the book, and didn't see any reference
> to multiple -c values. However, looking more closely, there is a
> sentence in the description section.
>
> The help from the command line, however, does display the syntax
> correctly for using multiple -c values.
>
> If I have time, I'll forward the problem to the SVN book people.
>
> Thanks,
> Daniel B.
>
> > -----Original Message-----
> > From: Mark Phippard [mailto:markphip@gmail.com]
> > Sent: Wednesday, 3 September 2008 6:41 AM
> > To: Daniel Becroft
> > Cc: users@subversion.tigris.org
> > Subject: Re: Cherrypicking Non-Sequential Revisions
> >
> > On Mon, Sep 1, 2008 at 11:02 PM, Daniel Becroft
> > <Da...@supercorp.com.au> wrote:
> >
> > > We need to be apply, to a given working copy, multiple, potentially
> > > non-successive changsets.
> > >
> > > For example, for a working copy of a branch @ revision 12,
> > we need to
> > > apply the changes to trunk in revisions 13-15, 23, 25-26, and 30.
> > >
> > > Is this possible with a single svn-merge command, or will
> > we need to
> > > do multiple commands?
> >
> > With SVN 1.5 this is possible to do with a single merge command.
> >
> > --
> > Thanks
> >
> > Mark Phippard
> > http://markphip.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1865056
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Cherrypicking Non-Sequential Revisions
Posted by marc gonzalez-carnicer <ca...@gmail.com>.
2009/4/27 Mike Meyer <mm...@lexmark.com>:
>
> marc gonzalez-carnicer <ca...@gmail.com> wrote on 04/25/2009
> 05:05:55 AM:
>
>> hi,
>>
>> 2009/4/24 Mike Meyer <mm...@lexmark.com>:
>> >
>> > marc gonzalez-carnicer <ca...@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.
ok, no problem -- don't know what P4 is :)
>
>> 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.
even if one tries to be careful (taking care with well written log
messages, etc), it's
still easy to make mistakes.
>> 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?
i have never been user of commercial unix besides solaris / sunos, but
i guess so. i was
amazed to find some old sun manuals where i could see it was first
developed in the
early 70s with a well-defined mathematical model.
sun replaced SCCS / teamware by CVS sometime around 2002, so we had to
be very careful not to lose the original CDs and their development
enviroments. we
realized that around 2004 and that's when i started to look for VCS
alternatives, and
i found out svn existed.
i'd say it should be somehow possible to do distributed development
with SCCS teamware. you
need to "bringover create" (svn checkout) or "bringover update" (svn
update) on a mounted
disk of the "parent" repo, and if you can physically take that disk to
your second development
environment it's fine. then in order to merge changes you would need
to mount back the disk
onto the first machine. but i never tried that.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1959277
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Cherrypicking Non-Sequential Revisions
Posted by Mike Meyer <mm...@lexmark.com>.
marc gonzalez-carnicer <ca...@gmail.com> wrote on 04/25/2009
05:05:55 AM:
> hi,
>
> 2009/4/24 Mike Meyer <mm...@lexmark.com>:
> >
> > marc gonzalez-carnicer <ca...@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@subversion.tigris.org].
Re: Cherrypicking Non-Sequential Revisions
Posted by marc gonzalez-carnicer <ca...@gmail.com>.
hi,
2009/4/24 Mike Meyer <mm...@lexmark.com>:
>
> marc gonzalez-carnicer <ca...@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 <mm...@lexmark.com>:
>> >
>> > marc gonzalez-carnicer <ca...@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@subversion.tigris.org].
Re: Cherrypicking Non-Sequential Revisions
Posted by Mike Meyer <mm...@lexmark.com>.
marc gonzalez-carnicer <ca...@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 <mm...@lexmark.com>:
> >
> > marc gonzalez-carnicer <ca...@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@subversion.tigris.org].
Re: Cherrypicking Non-Sequential Revisions
Posted by marc gonzalez-carnicer <ca...@gmail.com>.
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".
2009/4/22 Mike Meyer <mm...@lexmark.com>:
>
> marc gonzalez-carnicer <ca...@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=1890945
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Cherrypicking Non-Sequential Revisions
Posted by marc gonzalez-carnicer <ca...@gmail.com>.
hello Mark, many thanks for your reply.
2009/4/22 Mark Phippard <ma...@gmail.com>:
> On Wed, Apr 22, 2009 at 3:50 PM, marc gonzalez-carnicer
> <ca...@gmail.com> wrote:
>
>> 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.
>>
>> for reference, i am using svn 1.5.1 on the client and svn 1.3.2 on the
>> server side. i am not using mergeinfo, i can't yet.
>>
>> the syntax for that appears to be obvious, since examples of it
>> neither appear on the svnbook nor on the built-in help. finally, i end
>> up with a command like that :
>>
>>
>> $ svn merge \
>> -r 2471:2473 -r 2477:2479 -r 2484:2485 -r 2486:2491 \
>> -r 2492:2493 -r 2494:2496 -r 2505:2506 -r 2578:2586 \
>> -r 2596:2600 -r 2607:2610 -r 2611:2612 -r 2621:2624 \
>> -r 2626:2630 -r 2667:2668 \
>> svn://srv-peat-svn/home/svn/8568/branches/code.Lane.LNT .
>>
>> this variant seems to be possible too
>>
>> $ svn merge -c 2472,2473,2478,2479,2495,2487,2488,2489,2490,2491 \
>> svn://srv-peat-svn/home/svn/8568/branches/code.Lane.LNT .
>>
>>
>> to my surprise, neither command does NOT perform a unique merge
>> operation, and instead, as many merges as revision ranges specified.
>> this causes that if a file has been modified in more that one revision
>> group, it is merged more than once. if there are conflicts, the
>> situation becomes scary, and the WC a mess.
>>
>> i was expecting svn merge to behave as the good old svnmerge.py
>> script, now forgotten by many.
>>
>> am i doing something wrong or is it that svn merge can't perform these
>> multiple revision merge in just one try? if it is the latter case, i'd
>> appreciate confirmation about it.
> It does one merge for each revision range specified.
thanks for confirming it.
>This is also how
> svnmerge.py did it. After all, it used the svn command line to
> perform the merges so it cannot do anything the command like cannot.
i see. if i had that feeling it's probably because i may have not had
conflicts when i used svnmerge.py.
anyhow, i don't understand why svn merge, when invoked with multiple
revision ranges performs a merge for each range. is this an
intentional feature, or a design overlook? i really can't think of a
case when this would be useful. when a merge includes a *single*
revision range, only 1 merge is performed, even if the range contains
hundreds of revisions. to me, a multiple revision range is
conceptually *exactly* the same : a single merge operation.
i would expect a multiple revision range merge to internally produce a
diff-patch of all the specified revision ranges, and then merge it
with the WC (the target). some revision ranges may cancel some others,
and that would probably reduce the number of conflicts, if there are
any.
i can provide the log and results of my real-world example in order to
support my point of view :)
PS : i do hope my email does not sound harsh. my apologies in that
case. i can only be grateful towards subversion developers.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1891305
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Cherrypicking Non-Sequential Revisions
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Apr 22, 2009 at 3:50 PM, marc gonzalez-carnicer
<ca...@gmail.com> wrote:
> 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.
>
> for reference, i am using svn 1.5.1 on the client and svn 1.3.2 on the
> server side. i am not using mergeinfo, i can't yet.
>
> the syntax for that appears to be obvious, since examples of it
> neither appear on the svnbook nor on the built-in help. finally, i end
> up with a command like that :
>
>
> $ svn merge \
> -r 2471:2473 -r 2477:2479 -r 2484:2485 -r 2486:2491 \
> -r 2492:2493 -r 2494:2496 -r 2505:2506 -r 2578:2586 \
> -r 2596:2600 -r 2607:2610 -r 2611:2612 -r 2621:2624 \
> -r 2626:2630 -r 2667:2668 \
> svn://srv-peat-svn/home/svn/8568/branches/code.Lane.LNT .
>
> this variant seems to be possible too
>
> $ svn merge -c 2472,2473,2478,2479,2495,2487,2488,2489,2490,2491 \
> svn://srv-peat-svn/home/svn/8568/branches/code.Lane.LNT .
>
>
> to my surprise, neither command does NOT perform a unique merge
> operation, and instead, as many merges as revision ranges specified.
> this causes that if a file has been modified in more that one revision
> group, it is merged more than once. if there are conflicts, the
> situation becomes scary, and the WC a mess.
>
> i was expecting svn merge to behave as the good old svnmerge.py
> script, now forgotten by many.
>
> am i doing something wrong or is it that svn merge can't perform these
> multiple revision merge in just one try? if it is the latter case, i'd
> appreciate confirmation about it.
It does one merge for each revision range specified. This is also how
svnmerge.py did it. After all, it used the svn command line to
perform the merges so it cannot do anything the command like cannot.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1865347
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Cherrypicking Non-Sequential Revisions
Posted by Mike Meyer <mm...@lexmark.com>.
marc gonzalez-carnicer <ca...@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=1865409
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].