add build date to log

[Edgar]

post 2.0.0
in audacity.h ~ line 41, make beta & "stable" lines end with __TDATE__ like "alpha" does (which adds the BUILD date--and thus some commit version info); also change the trailing - (dash) to a space--it looks better IMVHO:
old:

Code: Select all

#if IS_ALPHA
   #define AUDACITY_SUFFIX wxT("-alpha-") __TDATE__ 
#elif (IS_BETA)
   #define AUDACITY_SUFFIX    wxT("-beta") 
#else
   #define AUDACITY_SUFFIX    wxT("") // for a stable release
#endif

new:

Code: Select all

#if IS_ALPHA
   #define AUDACITY_SUFFIX wxT("-alpha ") __TDATE__ 
#elif (IS_BETA)
   #define AUDACITY_SUFFIX    wxT("-beta ") __TDATE__ 
#else
   #define AUDACITY_SUFFIX    wxT(" ") __TDATE__ // for a stable release
#endif

[Gale Andrews]

post 2.0.0
in audacity.h ~ line 41, make beta & "stable" lines end with __TDATE__ like "alpha" does (which adds the BUILD date--and thus some commit version info); also change the trailing - (dash) to a space--it looks better IMVHO:

Can you say why? There is a policy not to release Audacity with the same version number and different contents (alphas are not strictly "releases").

There may be a better case for having the date of releases shown on the Audacity downloads pages.


Gale

[Edgar]

Can you say why?

The devs would really like to be able to ID the commit revision number for some bug reports. Search Bugzilla for "commit"--I asked if there was a way and got "No, but it sure would be nice". Having the build date on the betas (the "stable" is well known but you might as well have it for the sake of completion) as you already do on the alphas (it is part of the string which gets put at the top of the log) would help pin it down to a single day. That way parsing the commits would be a whole lot simpler.

[ragnar.jensen]

The devs would really like to be able to ID the commit revision number for some bug reports. Search Bugzilla for "commit"--I asked if there was a way and got "No, but it sure would be nice".

It is super easy to have Subversion doing it for you.

Code: Select all

svn propset svn:keywords "[Rev|Id|Date|Author|URL]" file

Then add

Code: Select all

$Rev|Id|Date|Author|URL $

to the file and commit.

Code: Select all

$ vi myfile.txt

>   $Rev: $

$ svn ci -m 'Add revision id to file' myfile.txt
$ less myfile.txt

> $Rev: 768 $

Same with the other tags of Id, Date, Author, URL

--
Ragnar

[Edgar]

It is super easy to have Subversion doing it for you.

I do not see how the user in the field can then tell the dev what the commit revision number is. I think your example adds a revision number to a source file; they want a revision number on the executable and a way the user can report it in a bug report.

[ragnar.jensen]

If the source file in question is AboutDialog.cpp:

About dialog with commit revision

about_audacity_w_svn_rev.png (11.52 KiB) Viewed 1950 times

EDIT: Oops, I was too fast! That will only show the revision when AboutDialog.cpp was last changed.
You'll need svnversion and a bit of external processing to get the global revision number into your file.

--
Ragnar

[Edgar]

That was my thought as well--the devs are not going to edit in something each commit. With adding the build date automatically they get very close and it shows in the Log.

[Gale Andrews]

Can you say why?

The devs would really like to be able to ID the commit revision number for some bug reports. Search Bugzilla for "commit"--I asked if there was a way and got "No, but it sure would be nice". Having the build date on the betas (the "stable" is well known but you might as well have it for the sake of completion) as you already do on the alphas (it is part of the string which gets put at the top of the log) would help pin it down to a single day. That way parsing the commits would be a whole lot simpler.

Bugzilla gives too many results for "commit".

My recollection was that Leland and I wanted to add revision number (to *alphas*) and Vaughan (or someone) did not, even if it could be done.

But same question - don't we know the commit number of a release? I do.


Gale

[billw58]

But same question - don't we know the commit number of a release? I do.

Certainly, because of the freeze. But there will be nightlies going forward, right? And if those nightlies had at the top of the log the latest commit number, I'd know for sure what I'm testing.

As an aside, I can't see the date/time stamp of commits in Google Code. All I can see is e.g. "Today (26 minutes ago)" or "Yesterday (27 hours ago)". I can infer from that the UTC of the commit, I suppose, but having it displayed would be much easier, and deal with the issue that was raised when I commented on bug 334 http://bugzilla.audacityteam.org/show_b ... id=334#c45 .

-- Bill

[Gale Andrews]

But same question - don't we know the commit number of a release? I do.

Certainly, because of the freeze. But there will be nightlies going forward, right?

Yes, and they will be alphas (I presume) which already have __TDATE__ appended to AUDACITY_SUFFIX.

And if those nightlies had at the top of the log the latest commit number, I'd know for sure what I'm testing.

Yes and that was what I was asking for (for the nightlies) but it cannot currently be done. Ed's change does not add the svn revision number anywhere.

As an aside, I can't see the date/time stamp of commits in Google Code. All I can see is e.g. "Today (26 minutes ago)" or "Yesterday (27 hours ago)". I can infer from that the UTC of the commit, I suppose, but having it displayed would be much easier, and deal with the issue that was raised when I commented on bug 334 http://bugzilla.audacityteam.org/show_b ... id=334#c45 .

Rather than look on http://code.google.com/p/audacity/source/list , the answer would be to subscribe to audacity-svn_AT_googlegroups.com (or just look at it online ).




Gale