On 21/10/2014 00:02, ki7mt wrote: > HI Bill, Hi Greg, > > Just for my own understanding here. Some background. I have been working mostly on the wsjtx-1.4 branch and merging my bugfixes there into the "trunk" wsjtx branch. I have also made a few commits to the "trunk" wsjtx branch only.
Joe has been doing like likewise. His latest batch of commits were to the "trunk" wsjtx branch and he had decided that they were worthy of the wsjtx-1.4 branch as well so he was querying the correct procedure to do that merge to replicate the changes on the v1.4 branch. His changes on the "trunk " interleaved with some of my merge commits from the v1.4 branch and also one of my "trunk" only commits. > > If the local branch was updated first (svn up), which should pull other > folks commits made to the rc branch, then using to block merge -rxx:xx, > should try to merge those in wsjtx devel branch, possibly causing > conflicts if previously merged, is that correct? You need to clarify what you mean by "local branch". In general before merging the destination branch workspace should be brought up to date before merging, probably better to have a different checkout altogether for merging so it is not tainted by any local changes. > > If that's correct, why, when should there be commits made to one branch > ( wsjtx-1.4 ) and not the wsjtx-devel branch? See my initial clarification above, there are commits to both branches and some of them are not supposed to get merged. In particular since Joe is merging from "trunk" to branch he must be very careful not to inadvertently sweep up any 1.5 only changesets in his merge. In theory merging a change that is already there in the destination branch should not result in issues (i.e. my merge commits in the branch - "trunk" directrtion) but the merge tracking in Subversion is not perfect and I personally don't trust it and always am absolutely specific about what changesets I want to merge. > > I understand the use of -c, and selecting specific commits, but I'm not > grasping why or when there should be a delta between the two branches to > begin with, particularly in a non-distributed workflow, or maybe that's > what is being changed here, I'm not sure, thus the reason I'm asking :-) In theory the only delta between branch and trunk in a "release branch" workflow should be the new changesets in the trunk, but in practice that is not quite true because the branch has at least two branch only changesets where the RC number was bumped from rc1 to rc2 and then rc3. But note again Joe was going from "trunk" to branch where there are definitely other changesets that should not be merged. > > 73's > Greg, KI7MT 73 Bill G4WJS. > > On 10/20/2014 04:39 PM, Joe Taylor wrote: >> Many thanks, Bill -- your reply has exactly the help I needed. >> >> -- Joe >> >> On 10/20/2014 5:58 PM, Bill Somerville wrote: >>> On 20/10/2014 20:20, Joe Taylor wrote: >>> >>> Hi Joe, >>>>> And then a final question, so that I do this right. I have parallel >>>>> working directories for .../branches/wsjtx and .../branches/wsjtx-1.4. >>>>> Will the following commands do the desired merge? >>>>> >>>>> > cd wsjtx >>>>> > svn merge -r4532:4544 ../wsjtx-1.4 . >>>> Sorry to be stupid about this. I think the correct steps I should take >>>> to merge my changes (from r4533 to r4544) into .../branches/wsjtx-1.4 >>>> are these: >>>> >>>> > cd wsjtx-1.4 >>>> > svn up >>>> > svn merge -r4532:4544 ../wsjtx . >>>> >>>> Do I have it right, now? >>> No that includes changes other than yours which will cause issues. >>> >>> First think to note is that the way svn merge works is that the changes >>> are applied to the current working directory but the source of the >>> changes is the repository. So you only need a checkout of the >>> destination branch to do a merge. It doesn't matter that you have >>> another working directory, it just isn't relevant here. >>> >>> I tend to use the '-c' switch to select the changsets I wish to merge, >>> that takes individual changeset numbers and IMHO is clearer than the >>> '-r' version so long as the list of changesets to merge is not too long. >>> So first I would list the changesets in the source branch to confirm I >>> have the correct ones e.g. >>> >>> svn log -c4533,4534,4535,4536,4537,4540,4544 ^/branches/wsjtx >>> >>> This command is standalone as it references the repository only. >>> >>> Once you are happy that you have the correct changesets, you can then do >>> the merge in a destination branch workspace. So in your workspace that >>> has the wsjtx-1.4 branch checkout: >>> >>> svn merge -c4533,4534,4535,4536,4537,4540,4544 ^/branches/wsjtx >>> >>> Note that this is conveniently the same as the log command above with >>> 'merge' substituted for 'log'. That will update your workspace with the >>> results of the merge. Then resolve any conflicts, note that conflicts >>> are possible even if you have no local edits. Then compile and test and >>> once you are happy that nothing is broken, commit the changes. >>>> -- Joe >>> 73 >>> Bill >>> G4WJS. >>> >>> ------------------------------------------------------------------------------ >>> Comprehensive Server Monitoring with Site24x7. >>> Monitor 10 servers for $9/Month. >>> Get alerted through email, SMS, voice calls or mobile push notifications. >>> Take corrective actions from your mobile device. >>> http://p.sf.net/sfu/Zoho >>> _______________________________________________ >>> wsjt-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> ------------------------------------------------------------------------------ >> Comprehensive Server Monitoring with Site24x7. >> Monitor 10 servers for $9/Month. >> Get alerted through email, SMS, voice calls or mobile push notifications. >> Take corrective actions from your mobile device. >> http://p.sf.net/sfu/Zoho >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
