kicad-developers team mailing list archive

[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
> 
> 
> 
>