I pushed your patch into the master branch. Thanks Nick.
On 9/15/2016 1:48 AM, Nick Østergaard wrote:
> I hereby attach a patch for the mising changes.
>
> 2016-09-15 3:25 GMT+02:00 Simon Wells :
>> Hey Wayne,
>>
>> just in regards to e7e165d WriteVersionHeader.cmake still references
>> the remo
I hereby attach a patch for the mising changes.
2016-09-15 3:25 GMT+02:00 Simon Wells :
> Hey Wayne,
>
> just in regards to e7e165d WriteVersionHeader.cmake still references
> the removed bzr files if you want to remove that stuff as well
>
> Simon
>
> On Tue, Sep 13, 2016 at 12:52 AM, Wayne Stamb
Hey Wayne,
just in regards to e7e165d WriteVersionHeader.cmake still references
the removed bzr files if you want to remove that stuff as well
Simon
On Tue, Sep 13, 2016 at 12:52 AM, Wayne Stambaugh wrote:
> Probably not. We can always resurrect it from the dead should the need
> be. I notice
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 CreateBZRVe
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 wrote:
> Den 09/09/2016 20.09 skrev "Wayne Stambaugh" :
>>
>> Have we come to any consensus on this yet
Den 09/09/2016 20.09 skrev "Wayne Stambaugh" :
>
> 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
Pushed. :)
On Fri, Sep 09, 2016 at 02:08:52PM -0400, Wayne Stambaugh wrote:
> 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
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
On lør, 2016-08-27 at 12:06 -0400, Chris Pavlina wrote:
> On Sat, Aug 27, 2016 at 11:02:49AM -0500, Bob Gustafson wrote:
> >
> > On 08/27/2016 10:55 AM, Chris Pavlina wrote:
> >
> > >
> > > On Sat, Aug 27, 2016 at 05:48:45PM +0200, jp charras wrote:
> > > >
> > > > Le 27/08/2016 à 17:14, Chris
The hash tag is in the revision string as well, so as long as the
revision string is supported we know exactly which commit was
used to build.
- Cirilo
On Sun, Aug 28, 2016 at 2:02 AM, Bob Gustafson wrote:
> On 08/27/2016 10:55 AM, Chris Pavlina wrote:
>
> On Sat, Aug 27, 2016 at 05:48:45PM +02
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 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 numb
On 08/27/2016 06:06 PM, Chris Pavlina wrote:
> Sure, if you're trying to pin down an _exact_ commit...but how does the
> fake bzr revno help you there? The bzr repo isn't used anymore, it's not
> like you can just check the bzr log for it.
>
> All you need is a sense of how old it is. If you need
On Sat, Aug 27, 2016 at 11:48 AM jp charras 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
On Sat, Aug 27, 2016 at 11:02:49AM -0500, Bob Gustafson wrote:
> On 08/27/2016 10:55 AM, Chris Pavlina wrote:
>
> >On Sat, Aug 27, 2016 at 05:48:45PM +0200, jp charras 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
>
On 08/27/2016 10:55 AM, Chris Pavlina wrote:
On Sat, Aug 27, 2016 at 05:48:45PM +0200, jp charras 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.
Additional
On Sat, Aug 27, 2016 at 05:48:45PM +0200, jp charras 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
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
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
18 matches
Mail list logo
