kicad-developers team mailing list archive

[Niki Guldbrand <niki.guldbrand@xxxxxxxxx>]

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 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).
> > > Just use the date! That's why it's there. If a user told me he
> > > had an
> > > issue with rev 1234 I have no idea how I'd go about converting
> > > that to a
> > > git commit now that bzr is gone. It's meaningless now except as a
> > > sequence, and...that's what the date is for!
> > This assumes that there is at most one revision per day..
> 
> 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 something more
> fine-grained you're going to need to look at the exact commit
> _anyway_.
> 
> I really would like someone to explain to me how these fake bzr
> revision
> numbers are useful _when the commits themselves aren't tagged with
> them_. If I give you "revision 7423", you can't just go jump to that
> revision, it's only useful in the context of "this is older than this
> build 7992 I have", and I don't think many of us are keeping around
> multiple builds from the same day...

As I see it the rev number is only useful for a particular cloned copy
of the repo.

What I mean by this is that if we say that launchpad master is at rev
1000, and my master is 10 commits behind (990), and I have for example
5 local commits on my master, and somthing in there fsck's somthing up,
and I report a bug, then you will get a revision number of 995 in the
bug report, but revisions 991 to 995 in launchpad master are different
from my revisions, which you can't see from the rev number, so some one
starts to dig into launchpad's master rev 991 to 995 to figure out what
is wrong, and wastes time, until giving up, or some one figures out
that it's something in my local, and that I have local commits that are
at fault.

So the rev number is not usefull for anything, other than showing the
number of commits in my own clone of the git repo.

-- 
Niki Guldbrand <niki.guldbrand@xxxxxxxxx>