Hi I don't see the patch anywhere. Please resend, I guess Joe only replied to you.
2015-09-13 19:51 GMT+02:00 Wayne Stambaugh <[email protected]>: > @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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
