kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 9/13/2015 11:40 PM, Joseph Chen wrote:
> @Wayne,
> 
> In case of emergency, you can reverse my previous patch by applying the
> attached patch.  It will revert to the clean state as before for the
> single file of CreateGitVersionHearder.cmake.
> 
> I am embarrassed that the previous patch causes lots of troubles for
> ones not using a true git repo in their development environment, and I
> apologized sincerely.

Not a problem.  That is why we using version control in the first place.
 I'll leave it to the git users to come up with a workable solution to
this problem.  I would look at it myself but I'm at my bandwidth limit
at the moment with all of the stable release stuff going on.

Cheers,

Wayne

> 
> --Joe Chen
> 
> On 09/13/2015 12:57 PM, Wayne Stambaugh wrote:
>> 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
>