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.bauma...@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@102", merged into the release branch? > > svn merge -c 102 ^/trunk .? > > Cheers, > Daniel B. > >
