Re: [wsjt-devel] v1.4 release matters - was: Compound callsigns
On 20/10/2014 17:10, Joe Taylor wrote: Hi Joe, > PS to my message of a few minutes ago: > > Perhaps we should also discuss whether the time for taggind and posting > "wsjtx-1.4.0-rc3" is approaching? (Is that the proper nomenclature, or > should it be wsjtx-1.4.1-rc1, or ???) Easy one first - wsjtx-1.4.0-rc3 since we haven't had a successful release candidate yet. As usual I am still climbing the rig control hill. I still have possibly major issues to resolve with emulated split mode and OmniRig stability. There is an issue with the TS-570(D) using Hamlib which I have not got to the bottom of. Some Yaesu rigs need some Hamlib work doing as they can't do split via Hamlib because the feature is missing. Testing is going well with some DX LAb Suite Commander issues but release isn't possible until Dave AA6YQ publishes the new version of Commander that will be required. A couple of the above issues will be seen as regressions since v1.3 so mainly for that reason I would like to try and get them sorted out before another release. If we release another candidate then I doubt it will be a real candidate and we would have to do another iteration. OTOH there are many fixes that have been applied and successfully tested by those reporting them. I notice that the Beta usage, as gauged by PSKReporter statistics, seems to have peaked at around 475 users which is about one fifth of the regular non developer WSJT-X users FWIW. > > -- 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
Re: [wsjt-devel] v1.4 release matters - was: Compound callsigns
Hi Bill and all, >> Perhaps we should also discuss whether the time for taggind and posting >> "wsjtx-1.4.0-rc3" is approaching? (Is that the proper nomenclature, or >> should it be wsjtx-1.4.1-rc1, or ???) > Easy one first - wsjtx-1.4.0-rc3 since we haven't had a successful > release candidate yet. OK, agreed. Also agree that we have a few more issues to sort out, before making another candidate release. I'm inclined to think, then, that the changes I made to message generation should be considered as bug fixes and merged back into wsjtx-1.4 -- even though they do, in fact, add some new functionality. Does this sound right? 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 . -- Joe -- 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
Re: [wsjt-devel] v1.4 release matters - was: Compound callsigns
> 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? -- Joe -- 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
Re: [wsjt-devel] v1.4 release matters - was: Compound callsigns
Hi Joe, Bill is probably be best authority on this but, what you posted below looks correct to me (at least on my local svn repo, that's how it works) and should post r4532 thru 4544 from wsjtx-1.4 into wsjtx development branch, assuming wsjtx is one level above. If you've not done so, you probably need to do a commit in the wsjtx devel branch after the merge, with a comment or something stating the changes were merged from the wsjtx-1.4 rc branch. 73's Greg, KI7MT On 10/20/2014 01:20 PM, Joe Taylor wrote: >> 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? > > -- Joe > > -- > 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
Re: [wsjt-devel] v1.4 release matters - was: Compound callsigns
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
Re: [wsjt-devel] v1.4 release matters - was: Compound callsigns
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
Re: [wsjt-devel] v1.4 release matters - was: Compound callsigns
HI Bill, Just for my own understanding here. 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? If that's correct, why, when should there be commits made to one branch ( wsjtx-1.4 ) and not the wsjtx-devel branch? 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 :-) 73's Greg, KI7MT 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
Re: [wsjt-devel] v1.4 release matters - was: Compound callsigns
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
Re: [wsjt-devel] v1.4 release matters - was: Compound callsigns
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 work
