I will have a look at the issue, but I am just doing a freash checkout of the source.
2015-09-13 20:57 GMT+02:00 Wayne Stambaugh <[email protected]>: > Please throw me together a quick patch so I can fix it. I just > committed Joseph's patch. Would these changes fix the issue @Simon just > reported? > > On 9/13/2015 2:14 PM, Nick Østergaard wrote: >> Looks ok to me, except that the naming of the _git_LONG_HASH_ORIGIN >> variable does not match what it is, it should have been >> _git_LONG_HASH_LOCAL instead. >> >> And the line, >> >> message(STATUS "Git hash: ${_git_LONG_HASH_ORIGIN}") >> >> should also be corrected, I guess. >> >> >> 2015-09-13 20:05 GMT+02:00 Wayne Stambaugh <[email protected]>: >>> Joseph, >>> >>> I committed your patch in the product branch r6191. Thank you for you >>> contribution to KiCad. >>> >>> Cheers, >>> >>> 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 > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
