tools/version.sh: fix compilation of shallow clones

[guijan]

See the commit message for details.

Also, maybe we don't need to keep track of this SVN revision number stuff now that Aegisub is on git? That would remove a bit of code.

[Totto16]

#165 is similar / does the same.
But not sure which one is better, but both solve the same problem

[petzku]

Also, maybe we don't need to keep track of this SVN revision number stuff now that Aegisub is on git? That would remove a bit of code.

As I understand, this exists to keep the revision numbers consistent? Seeing as the total rev-count on git up to SVN r6962 (i.e. 16cd907) is only 5849. That said, this could also be accomplished without breaking shallow clones (though producing incorrect revision numbers; your solution is certainly better in that regard) using $(git rev-parse --count HEAD) + 1113 instead.

[guijan]

though producing incorrect revision numbers

Aegisub/src/version.cpp

Lines 81 to 86 in 921249c

	int GetSVNRevision() {
	#ifdef BUILD_GIT_VERSION_NUMBER
	return BUILD_GIT_VERSION_NUMBER;
	#else
	return 0;
	#endif

I just went with what the code already seemed to want to do, although the #else branch is never triggered because the current meson.build and version.sh from master will always define BUILD_GIT_VERSION_NUMBER for shallow clones

[petzku]

Yeah, this behavior is quite reasonable; i just meant that if one were to blindly evaluate

git_revision=$(expr 1113 + $(git rev-list --count HEAD))

you would end up with an incorrect version number (likely 1114) for a shallow clone, rather than 0.

[petzku]

Either way, the logic to keep counting SVN revision numbers seems reasonable to me, if only for familiarity -- since for a long while (while upstream was stale), Aegisub builds were most commonly referred to by their revision numbers. Changing the logic for this would mean a change in how those revision numbers are calculated, making new revision numbers no longer sequential with the old ones (though, by my understanding, there is no real need for them)

[FichteFoll]

The SVN revision number is not a thing we should bend over backwards to maintain. Especially if we consider the repo setup to be usable now with more frequent releases and CI builds, I would rather go the git describe route and fall back to just the commit hash if no git tag can be found, which will also work in any shallow clone. It's just that the version number of the closest tag in the history is not always available in that case, but I find hard-coding the latest release version a reasonable approach.

In short, the logic I propose to build a version number/string is:

1. if "official release", take it from the hard-coded version number. This requires keeping this number up to date, of course.
2. else, build it from the hard-coded version number + number of commits since the lastest tag (if available) + the commit hash. May also want to throw in dev somewhere to indicate that this is a dev build.

---

Edit: forgot to comment on the actual PR. For now, this is probably a reasonable workaround and better than #165.

[aniolm9]

Preparing the Debian package I noticed that the build fails when using the tarball:

[2/362] /builds/debian/aegisub/debian/output/source_dir/tools/version.sh /builds/debian/aegisub/debian/output/source_dir/obj-x86_64-linux-gnu /builds/debian/aegisub/debian/output/source_dir
FAILED: git_version.h 

Maybe git_version.h should be added in the release tar?