kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #20292
Re: [PATCH] Fixed a False BZR Version Number Built From Local Branch of GIT-Source-Mirror
-
From:
Wayne Stambaugh <stambaughw@xxxxxxxxx>
-
Date:
Fri, 11 Sep 2015 10:27:06 -0400
-
Cc:
KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
-
In-reply-to:
<CAOuK9LgJ7qOk7F=YMoDG-rYo=qToBkf1mm0b6aSKeABk=6dUSg@mail.gmail.com>
-
User-agent:
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
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
>>
>>
References