@Nick, Where these the changes you were looking for?
Wayne On 9/13/2015 12:50 AM, Joseph Chen wrote: > > @Wayne & @Nick, > > Attached you can find the new patch file that I've incorporated the > Nick's inputs. > > Thanks, > > --Joe > > > On 09/11/2015 08:27 AM, Wayne Stambaugh wrote: >> Joseph, >> >> Please make these changes and resubmit your patch and I will commit it. >> >> Thanks, >> >> Wayne >> >> On 9/11/2015 10:19 AM, Nick Østergaard wrote: >>> Hi Joseph >>> >>> Yes, I agree with you and understand the reasoning. I was just not >>> able to see the file patched and only reviewed the patch file itself. >>> I have now tried to apply it. >>> >>> Some comments: >>> >>> 1. The line just before "# Get origin Repo HEAD" should probably be an >>> empth line to match the rest of the execute_process'. >>> >>> 2. We also create a long hash variable, although it is not used >>> anywhere else than for the cmake messaging, but we should probably me >>> explicit on which exact has that is. As is not that is a _LOCAL hash. >>> This to match the short hash. >>> >>> If you adjust those two points, I think it is fine to merge it. >>> >>> 2015-09-11 10:16 GMT+02:00 Joseph Chen <[email protected]>: >>>> Hi Nick, >>>> >>>> I very much like the true BZR version number that is produced by >>>> your script >>>> when compiling from the git mirror source. This is very helpful when >>>> tracking the matching version of KiCAD from the bzr repo. >>>> >>>> In the new way that I proposed for producing BZR version number, I >>>> pretty >>>> much borrowed the tick that is being used by Linux kernel: when a >>>> cloned >>>> local source tree is the same as the up stream's, the version string >>>> is like >>>> "3.2.1" as the official release number. But, after some changes, the >>>> version string becomes "3.2.1-dirty-f6cd3", where "f6cd3" is the >>>> short hash >>>> of the local head. This means that the version is not official >>>> release any >>>> more. >>>> >>>> I hope this trivial patch can help in distinguish a true BZR version >>>> from >>>> those with local modifications. >>>> >>>> --Joe >>>> >>>> >>>> On 09/10/2015 05:54 PM, Nick Østergaard wrote: >>>>> Hi >>>>> >>>>> This is a matter of what we really want. When I wrote the logic at >>>>> first, my goal was just to make sure to generate a bzr version that >>>>> matches how the bzr cmake module did it, when building with an >>>>> unmodified tree. I think my version complies to that; that is not >>>>> taking care about weather or not you are on a local banch. >>>>> >>>>> I have not tested this patch, but it looks alright to me. I am fine >>>>> with extending it with this detail, although one could argue that >>>>> holding the bzr rev as is, is not entirely correct, but if you get the >>>>> complete version string you can deduce that there are changes. For >>>>> example as you state the HEAD for the bzr number, you could also state >>>>> the HEAD and origin/HEAD for the bzr number, like, BZR 1234-1236 if >>>>> you have two commits in difference from the product branch. >>>>> >>>>> I am ok with either, but some people might find it odd as is. >>>>> >>>>> But I think the patch is not complete, the auxilarry variables should >>>>> probably be of the last local commit. That is the variables like >>>>> _git_LAST_COMITTER and _git_LONG_HASH. (Maybe they are ok, hard to see >>>>> properly in the patch only, I did not apply it.) >>>>> >>>>> Nick >>>>> >>>>> 2015-09-10 17:15 GMT+02:00 Wayne Stambaugh <[email protected]>: >>>>>> @Nick, have you had a chance to look at this patch? Since you wrote >>>>>> this I thought you should have some input. I'm not sure if this the >>>>>> correct behavior when using git to generate the KiCad version string. >>>>>> It seems as though Joseph is correct. Would you please take a >>>>>> look at >>>>>> it when you get a chance and let me know if it should be committed. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Wayne >>>>>> >>>>>> On 8/30/2015 4:24 PM, Joseph Chen wrote: >>>>>>> Please review and apply the attached patch file of >>>>>>> CreateGitVersion.cmake. >>>>>>> >>>>>>> *Issue to be fixed: a False BZR version number** >>>>>>> * >>>>>>> The details: >>>>>>> After cloning the repo of git-source-mirror, and working in my >>>>>>> own local >>>>>>> branch, and committing a X times, the BZR version-number that is >>>>>>> generated by file CreateGitVersion.cmake is incremented by X number. >>>>>>> This is a mismatch of the true BZR number. >>>>>>> >>>>>>> The tests: >>>>>>> _Before applying this patch_: >>>>>>> >>>>>>> The command "Copy Version Info" built from the origin "master" >>>>>>> branch >>>>>>> displays the following: >>>>>>> Version: (2015-08-30 *BZR 6134, Git 4e94d52*)-product >>>>>>> release >>>>>>> build >>>>>>> which is correct. >>>>>>> >>>>>>> _However_, after creating a local branch based off the "master" >>>>>>> branch, >>>>>>> and having committed 2 more times in the local branch, the >>>>>>> command "Copy >>>>>>> Version Info" built from the local branch displays the following >>>>>>> false >>>>>>> BZR number: >>>>>>> Version: (2015-08-30 *BZR 6136, Git edfb32e*)-product >>>>>>> release >>>>>>> build >>>>>>> which is _false_, because at the time the official BZR number is >>>>>>> only >>>>>>> *6134*. >>>>>>> >>>>>>> >>>>>>> _After applying this_patch_: >>>>>>> The command "Copy Version Info" built from the "master" branch >>>>>>> displays >>>>>>> the following: >>>>>>> Version: (2015-08-30 *BZR 6134, Git 4e94d52*)-product >>>>>>> release >>>>>>> build >>>>>>> which is still correct. >>>>>>> >>>>>>> Now, the command "Copy Version Info" built from the local branch >>>>>>> that >>>>>>> has 2 extra commits displayes the following: >>>>>>> Version: (2015-08-30 *BZR 6134, Git >>>>>>> 4e94d52-ede23f9*)-product >>>>>>> release build >>>>>>> which is still correct with a _true_ *BZR 6134*, plus it has an >>>>>>> *added >>>>>>> GIT short hash* from the local branch HEAD. >>>>>>> >>>>>>> This added GIT short hash tells us that the running version is built >>>>>>> based off a true BZR 6134, plus some local modifications up to >>>>>>> GIT short >>>>>>> hash of *ede23f9.* >>>>>>> >>>>>>> --Joe >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>> Post to : [email protected] >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>> Post to : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>> More help : https://help.launchpad.net/ListHelp >>>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
