Hi Daniel,
I am certain that I had tried that previously and it didn't work.
Well the command worked, of course.... but the results were not what I was expecting.
Up until recently we did not have a "staged" release strategy.
We did continuous deployment of ALL changes submitted to the repostory;
So all merges were;
svn merge ^/trunk -r1:head .
Though to be fair, when I was trying to get it to work (cherry-picking), I was doing all sorts of "stuff" to see what did / didn't work.
So it is entirely possible that my "testing" was less than clean / elegant and thus, the results were flawed.
In fact, it had surprised me at the time that it didn't simply work, as advertised.
Anyway.... thanks very much for the reply....
I feel a little stupid, for the answer being so simple - but even the stupid questions can sometimes bear good results.
Thanks again....
Gavin.
On 31/10/2011, at 11:49 AM, Daniel Becroft wrote:
> On Mon, Oct 31, 2011 at 10:18 AM, Gavin "Beau" Baumanis <gavin.baumanis_at_palcare.com.au> wrote:
> Hi Everyone,
>
> I hoping that I can get some help with the theory of cherry-picking merges to a branch.
>
> I have the "default" subversion layout;
> /trunk
> /branches
> /tags
>
> I have a "release branch"; ^/branches/releases/1.5
>
> I have "^/trunk/filename.txt"
> I have just created a release branch, made some changes and created a tag for release.
> ^/tags/1.5
>
> The repo revision is @100.
>
> A colleague makes a some changes, so no filename.txt is @r101.
> I make a critical bug fix (unrelated to r101) and now "^/trunk/filename.txt" is at r102.
>
> I want to a make a "point" release, so as to get the bug-fix out to customers.
> But the changes made at r101 are not ready for release, yet.
>
> How do I go about getting "just" the changes made in "^/trunk.fiename.txt_at_102", merged into the release branch?
>
> svn merge -c 102 ^/trunk .?
>
> Cheers,
> Daniel B.
>
>
Received on 2011-10-31 02:22:20 CET