View Issue Details

IDProjectCategoryView StatusLast Update
0004679The Dark ModCodingpublic22.11.2017 17:15
Reportergrayman Assigned Tostgatilov  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
Product VersionSVN 
Target VersionTDM 2.06Fixed in VersionTDM 2.06 
Summary0004679: Highest revision number is no longer available
DescriptionThe routine GetHighestRevision() provides the highest SVN revision number for files used in a particular build.

This number is printed on the console when you pull it down, and is also used in savegame/loadgame checking.

The number comes from running the pre-build program gen_svnversion.cmd (Windows) (and something similar in the Linux scons build). I believe this program reads the svn version number comments in the source files, looking for the highest version number. It then stores that number in string form in the file svnversion.h as the define SVN_WORKING_COPY_VERSION.

At some point during 2.06 development, the svn version number comments were stripped from the source files, rendering this process useless. I don't know the effect this has on the savegame/loadgame version-checking code, but the version number painted on the console is now "0".
Additional InformationIs there a way to get back the svn version number of the build, or do we have to:

a - strip the version number from the command line
b - render the savegame/loadgame version checking irrelevant in the code
TagsNo tags attached.

Activities

nbohr1more

nbohr1more

20.11.2017 22:34

developer   ~0009648

As I recall, for the revision to work you must build the matching ExtLibs.dll
stgatilov

stgatilov

21.11.2017 02:22

administrator   ~0009649

This is caused by:
  http://forums.thedarkmod.com/topic/18841-disable-svnkeywords/?hl=svnversion#entry408462
Not related to ExtLibs.

Please write which platform do you have on the machine which does not detect revision, and which SVN client do you have.

Also try to run "svnversion" in SVN root directory in windows console (or Far Manager). It must print you the current revision number (7286 in my case). If it does not do this, try to make it work. svnversion is the standard command of SVN.

If svnversion works, then you should try to run explicitly gen_svnversion.cmd and check if idlib/svnversion.h is correct after that. If on Linux, then you should run scons build: it generates svnversion as the very first step and prints "Inserted SVN revision number into svnversion.h".
stgatilov

stgatilov

21.11.2017 02:24

administrator   ~0009650

Of course, the revision number is still necessary and useful.
But it is no longer coming from the source code files, it comes from SVN client directly now using svnversion.
grayman

grayman

21.11.2017 13:19

viewer   ~0009653

And the SVN root directory is where?
grayman

grayman

21.11.2017 13:20

viewer   ~0009654

Windows 7
Tortoise SVN
grayman

grayman

21.11.2017 13:22

viewer   ~0009655

I looked through the project properties and I don't see where svnversion is run as a pre-build command.
stgatilov

stgatilov

21.11.2017 15:20

administrator   ~0009656

It is run as pre-build event of idLib:
  cd $(ProjectDir) call gen_svnversion.cmd
SVN root directory is the directory to which you checked out the coding SVN. The one where gen_svnversion.cmd is located, and where MSVC solution is located.

Did you try to run svnversion in console?
Did you try to run gen_svnversion.cmd manually?
stgatilov

stgatilov

21.11.2017 15:23

administrator   ~0009657

Ok, how long ago did you install your TortoiseSVN client?
Did you enable command line tools during install? Can you write "svn up" in console so that Windows knows what the hell "svn" is?

Consider reinstalling TortoiseSVN, and make sure you enable command line client tools as shown here:
  https://stackoverflow.com/a/9874961/556899
nbohr1more

nbohr1more

21.11.2017 15:49

developer   ~0009658

"It is run as pre-build event of idLib:"

Eg. Isn't idLib now located in ExtLibs.dll?
stgatilov

stgatilov

21.11.2017 15:55

administrator   ~0009659

Last edited: 21.11.2017 15:56

Of course not.
ExtLibs is for external dependencies (like OpenAL, FFmpeg), and idLib is the inherent part of TDM engine. It is a static library linked into the engine executable.
And idLib contains the RevisionTracker of TDM, hence the custom build step is put on it, not on the engine.

grayman

grayman

21.11.2017 16:39

viewer   ~0009660

Reinstalled TSVN.

Enabled command line client tools.

Ran gen_svnversion.cmd.

svnversion.h now shows the latest rev.

However, building TheDarkModTools claims it can no longer find ExtLibs.dll.
stgatilov

stgatilov

21.11.2017 17:09

administrator   ~0009662

That is some progress =)

Did you try full solution rebuild?
Do you see ExtLibs.dll in darkmod_src or in darkmod directory? If yes, perhaps delete it and check if build creates it again.
Is anything different if you run TheDarkMod.exe manually from darkmod directory instead of from debugger? Do you run TheDarkMod.exe from darkmod directory?
Maybe last build failed for some reason?

To be honest, I have no idea how the fact that it does not find ExtLibs.dll can be caused by SVN client change. It should some generic "something did not get built/updated/created/run" issue.
grayman

grayman

22.11.2017 02:11

viewer   ~0009666

I rebuilt the SVN binaries (clean, build) and the build had no problem finding ExtLibs*, but now I'm getting this fatal error for the Win32 build:

C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include\afx.h(24): fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]

The 64-bit build completed properly.
grayman

grayman

22.11.2017 02:16

viewer   ~0009667

Using full solution rebuild in the 2.06 source build cleared the ExtLibs* problem, but I'm seeing the same Win32 fatal error as in the SVN source build.
stgatilov

stgatilov

22.11.2017 02:23

administrator   ~0009668

That's MayaImport project.
It does not build now. And it is not included in 64-bit build.
stgatilov

stgatilov

22.11.2017 02:25

administrator   ~0009669

Anyway, the original problem is gone.

Should we add a GUI message which pops on startup in case SVN version is not available? Although it won't work if you had svnversion working on your local copy, and then reinstalled SVN and it stopped working.
grayman

grayman

22.11.2017 02:25

viewer   ~0009670

After running the 32- and 64-bit linux builds, svnversion.h--properly filled in during the Windows builds--gets cleared.

Problem in SConstruct file?
stgatilov

stgatilov

22.11.2017 04:01

administrator   ~0009671

Just the same: try running svnversion in terminal and see if it prints the revision number. Perhaps you have to install svn or svnversion package.

Also you can try to run:
  sed "s/\!SVNVERSION\!/$(svnversion)/g" idlib/svnversion_template.h >idlib/svnversion.h
in the root directory of coding SVN.
grayman

grayman

22.11.2017 15:06

viewer   ~0009674

Installed subversion on the linux guest box.

svnversion.h is now correctly filled in after both linux builds.

Thanks for the help!
stgatilov

stgatilov

22.11.2017 17:15

administrator   ~0009678

Sorry for trouble!

Anyway, I'd like to repeat my question:
  Should we add a GUI message which pops on startup in case SVN version is not available?
Anyone can easily forget to install something from SVN and produce binaries which don't know SVN version. Putting such binaries into another SVN is not good, putting them into release package may be disastrous...

Issue History

Date Modified Username Field Change
20.11.2017 22:04 grayman New Issue
20.11.2017 22:04 grayman Status new => assigned
20.11.2017 22:04 grayman Assigned To => stgatilov
20.11.2017 22:34 nbohr1more Note Added: 0009648
21.11.2017 02:22 stgatilov Note Added: 0009649
21.11.2017 02:24 stgatilov Note Added: 0009650
21.11.2017 13:19 grayman Note Added: 0009653
21.11.2017 13:20 grayman Note Added: 0009654
21.11.2017 13:22 grayman Note Added: 0009655
21.11.2017 15:20 stgatilov Note Added: 0009656
21.11.2017 15:23 stgatilov Note Added: 0009657
21.11.2017 15:49 nbohr1more Note Added: 0009658
21.11.2017 15:55 stgatilov Note Added: 0009659
21.11.2017 15:56 stgatilov Note Edited: 0009659
21.11.2017 16:39 grayman Note Added: 0009660
21.11.2017 17:09 stgatilov Note Added: 0009662
22.11.2017 02:11 grayman Note Added: 0009666
22.11.2017 02:16 grayman Note Added: 0009667
22.11.2017 02:23 stgatilov Note Added: 0009668
22.11.2017 02:25 stgatilov Note Added: 0009669
22.11.2017 02:25 grayman Note Added: 0009670
22.11.2017 04:01 stgatilov Note Added: 0009671
22.11.2017 15:06 grayman Note Added: 0009674
22.11.2017 15:08 grayman Status assigned => resolved
22.11.2017 15:08 grayman Resolution open => fixed
22.11.2017 15:08 grayman Fixed in Version => TDM 2.06
22.11.2017 17:15 stgatilov Note Added: 0009678