Hi Bill, Ok, thanks, that's makes sense now. I didn't know some commits were being made only to one and not the other wsjtx-1.4 branch / wsjtx trunk.
The other question you answered also about the rc only commits regarding rc1, 2, 3 etc. Thanks 73's Greg, KI7MT On 10/20/2014 23:21, Bill Somerville wrote: > 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 >>>> wsjt-devel@lists.sourceforge.net >>>> 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 >>> wsjt-devel@lists.sourceforge.net >>> 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 >> wsjt-devel@lists.sourceforge.net >> 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 > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- 73's Greg, KI7MT ------------------------------------------------------------------------------ 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
