Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 38340: /trunk/ /trunk/: make-version

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Wed, 07 Sep 2011 21:58:24 -0400
On 08/05/2011 09:32 AM, Jeff Morriss wrote:
Joerg Mayer wrote:
On Thu, Aug 04, 2011 at 06:33:34PM -0400, Jeff Morriss wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=38340

User: cmaynard

Don't report svn version if not building from svn. Change prompted
by
http://ask.wireshark.org/questions/5376/wireshark-161-title-shows-svn-rev-unknown-from-unknown.

+3 -2 make-version.pl Modified

Does this really make sense? How do you differentiate between the
"real"
1.6.1 release and a post 1.6.1 source code archive?
I think this particular "fix" is wrong.
The only way I see to get around that, though, is to have each
official release (e.g., 1.6.1) have a commit to disable the SVN
version noise and then another commit to re-enable it after the
release is made.

Why not simply include the version.conf file in the tarball, shouldn't
that
fix the problem?

Ah, yes, that could do the trick. I hadn't realized that there actually
was a version.conf file in the release branches (and that Gerald already
updates it for each release).

Only problem seems to be that builds (e.g., the users' builds) always
call make-version and make-version always (unless it's doing a
package-version(?)) updates svnversion.h (even if there's a
version.conf). The fact that svnversion.h is in the source tarball may
also have an effect here.

Oof, sorry, I got pulled away from looking at this. But I checked in a change in r38933 which should address the issue: 38340 is reverted but release tarballs (at least those from the release branches--where we have a version.conf) won't even try using SVN (if the user is using a source tarball why would they have SVN?).

I'll schedule that for 1.6.3 once the queue opens.