Probably not. We can always resurrect it from the dead should the need be. I noticed the subversion stuff is still in there as well and we haven't used svn since 2009. I'll remove it when I get a chance.
On 9/10/2016 4:47 PM, Simon Wells wrote: > Is there any point in keeping around CreateBZRVersionHeader.cmake and > FindBzr.cmake as i am not sure there is any bzr distribution methods > left > > On Sun, Sep 11, 2016 at 12:21 AM, Nick Østergaard <oe.n...@gmail.com> wrote: >> Den 09/09/2016 20.09 skrev "Wayne Stambaugh" <stambau...@gmail.com>: >>> >>> Have we come to any consensus on this yet? I'm not sure the fake bzr >>> revision numbers have any meaning. Git doesn't have any concept of >>> linear commits so having a linear number will only make sense when >>> building from the master repo. These numbers will not track upstream >>> for anything built from a local repo that has deviated from the main >>> repo. >> >> This was also the case for BZR :) >> >>> I'm leaning towards not using them. The hash is always accurate. >>> If the is a commit hash that's not in the main repo, then it's obvious >>> that the build is someone's custom commits. I'm OK with this patch as >>> is. If there are no majo objects, @Chris go ahead and commit it. >>> >>> On 8/27/2016 2:49 PM, Mark Roszko wrote: >>>> rev 1234 the same meaning as rev 67230ac, you have to look it up >>>> regardless on git. >>>> >>>> On Sat, Aug 27, 2016 at 11:48 AM, jp charras <jp.char...@wanadoo.fr> >>>> wrote: >>>>> Le 27/08/2016 à 17:14, Chris Pavlina a écrit : >>>>>> Now that we've migrated from bzr, there isn't much reason to keep >>>>>> attaching a (now fake) bzr revision number to the version string. >>>>>> Additionally, we can choose a sensible default branch name if one >>>>>> isn't >>>>>> specified on the cmake line, rather than "product". This patch >>>>>> reformats >>>>>> the version strings to: >>>>>> >>>>>> (2016-08-26 revision 67230ac)-master >>>>>> | | | >>>>>> | | custom branch name if set. Otherwise, >>>>>> | | branch name, "HEAD" if not on a branch, >>>>>> | | or "unknown" if no .git present >>>>>> | | >>>>>> | abbreviated commit hash, or no-git if no .git >>>>>> | present >>>>>> | >>>>>> date of commit, or date of build if no .git present >>>>> >>>>> I find the bzr revision number useful to easily know the order of >>>>> revisions. >>>>> the name bzr is now a bit strange, so the version string could be: >>>>> >>>>> (2016-08-26 rev 1234 git 67230ac)-master >>>>> >>>>> (users, many times, just give a rev number, no the full version string, >>>>> so in a bug or mail, rev >>>>> 1234 has meaning, but revision 67230ac has no meaning, at least for >>>>> me). >>>>> >>>>> -- >>>>> Jean-Pierre CHARRAS >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>> Post to : kicad-developers@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
