If the local checkout does not have 'git svn' references set up, don't try
to use 'git svn' for version information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169749 91177308-0d34-0410-b5e6-96231b3b80d8
revision and git commit data extracted. This will be used in the Clang
CMake build to avoid trying to re-detect the information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146324 91177308-0d34-0410-b5e6-96231b3b80d8
in CMake a bit more handy. Previously we would get such charming
versions as the following for revision NNNN and commit-ish XXXXX:
3.1svnsvn-rNNNN
3.1svngit-svn-rNNNN
3.1svngit-svn-XXXXX
The mechanism selecting betwene the latter two was particularly odd, and
didn't work with all of the ways git-svn repos are set up apparently. It
also misses an important point -- both the revision *and* the git commit
might be relevant when working on a local branch some distance from
mainline. The new logic does several things:
1) It strips the redundant initial 'svn'.
2) It always looks for a git-svn revision number base, and when found
includes it in the version.
3) If the git commit-ish for the current HEAD is not exactly that
revision number, it is also included.
The resulting strings should roughly be:
3.1svn-rNNNN
3.1git-svn-rNNNN
3.1git-svn-rNNNN-XXXXX
Suggestions on formatting etc always welcome. =] I've only looked at the
LLVM version string here, not Clang's (yet).
Note that the commit-ish reported is *not* terribly accurate. It updates
when 'cmake' is run, not when the binary is built. Still, it may be
better than nothing, especially if people have fairly long-lived git
repos and branches. This is not a new limitation, just didn't want
anyone to be surprised.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146323 91177308-0d34-0410-b5e6-96231b3b80d8
