kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

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 <stambaughw@xxxxxxxxx>:
> 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 <stambaughw@xxxxxxxxx>:
>>> 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 <joseph.chen59@xxxxxxxxx>:
>>>>>>> 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 <stambaughw@xxxxxxxxx>:
>>>>>>>>> @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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>