2006-04-24 17:11:45 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
2013-04-08 18:24:50 +00:00
|
|
|
AWK=${AWK:-awk}
|
|
|
|
GIT=${GIT:-git}
|
|
|
|
GREP=${GREP:-grep}
|
build: Refactor the earlier "basebranch" commit
Recap from earlier commit: If you have a development branch for a
major project that will receive gerrit reviews it'll probably be
named something like "development/16/newproject" or a work branch
based on that "development" branch. That will necessitate
setting "defaultbranch=development/16/newproject" in .gitreview.
The make_version script uses that variable to construct the
asterisk version however, which results in versions
like "GIT-development/16/newproject-ee582a8c7b" which is probably
not what you want. It also constructs the URLs for downloading
external modules with that version, which will fail.
Fast-forward:
The earlier attempt at adding a "basebranch" variable to
.gitreview didn't work out too well in practice because changes
were made to .gitreview, which is a checked-in file. So, if
you wanted to rebase your work branch on the base branch, rebase
would attempt to overwrite your .gitreview with the one from
the base branch and complain about a conflict.
This is a slighltly different approach that adds three methods to
determine the mainline branch:
1. --- MAINLINE_BRANCH from the environment
If MAINLINE_BRANCH is already set in the environment, that will
be used. This is primarily for the Jenkins jobs.
2. --- .develvars
Instead of storing the basebranch in .gitreview, it can now be
stored in a non-checked-in ".develvars" file and keyed by the
current branch. So, if you were working on a branch named
"new-feature-work" based on "development/16/new-feature" and wanted
to push to that branch in Gerrit but wanted to pull the external
modules for 16, you'd create the following .develvars file:
[branch "new-feature-work"]
mainline-branch = 16
The .gitreview file would still look like:
[gerrit]
defaultbranch=development/16/new-feature
...which would cause any reviews pushed from "new-feature-work" to
go to the "development/16/new-feature" branch in Gerrit.
The key is that the .develvars file is NEVER checked in (it's been
added to .gitignore).
3. --- Well Known Development Branch
If you're actually working in a branch named like
"development/<mainline_branch>/some-feature", the mainline branch
will be parsed from it.
4. --- .gitreview
If none of the earlier conditions exist, the .gitreview
"defaultbranch" variable will be used just as before.
Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
2022-02-17 09:26:46 -07:00
|
|
|
SED=${SED:-sed}
|
|
|
|
|
2013-04-08 18:24:50 +00:00
|
|
|
|
2006-04-24 17:11:45 +00:00
|
|
|
if [ -f ${1}/.version ]; then
|
2009-03-12 01:33:04 +00:00
|
|
|
cat ${1}/.version
|
2012-10-18 20:13:17 +00:00
|
|
|
elif [ -d ${1}/.svn ]; then
|
build: Refactor the earlier "basebranch" commit
Recap from earlier commit: If you have a development branch for a
major project that will receive gerrit reviews it'll probably be
named something like "development/16/newproject" or a work branch
based on that "development" branch. That will necessitate
setting "defaultbranch=development/16/newproject" in .gitreview.
The make_version script uses that variable to construct the
asterisk version however, which results in versions
like "GIT-development/16/newproject-ee582a8c7b" which is probably
not what you want. It also constructs the URLs for downloading
external modules with that version, which will fail.
Fast-forward:
The earlier attempt at adding a "basebranch" variable to
.gitreview didn't work out too well in practice because changes
were made to .gitreview, which is a checked-in file. So, if
you wanted to rebase your work branch on the base branch, rebase
would attempt to overwrite your .gitreview with the one from
the base branch and complain about a conflict.
This is a slighltly different approach that adds three methods to
determine the mainline branch:
1. --- MAINLINE_BRANCH from the environment
If MAINLINE_BRANCH is already set in the environment, that will
be used. This is primarily for the Jenkins jobs.
2. --- .develvars
Instead of storing the basebranch in .gitreview, it can now be
stored in a non-checked-in ".develvars" file and keyed by the
current branch. So, if you were working on a branch named
"new-feature-work" based on "development/16/new-feature" and wanted
to push to that branch in Gerrit but wanted to pull the external
modules for 16, you'd create the following .develvars file:
[branch "new-feature-work"]
mainline-branch = 16
The .gitreview file would still look like:
[gerrit]
defaultbranch=development/16/new-feature
...which would cause any reviews pushed from "new-feature-work" to
go to the "development/16/new-feature" branch in Gerrit.
The key is that the .develvars file is NEVER checked in (it's been
added to .gitignore).
3. --- Well Known Development Branch
If you're actually working in a branch named like
"development/<mainline_branch>/some-feature", the mainline branch
will be parsed from it.
4. --- .gitreview
If none of the earlier conditions exist, the .gitreview
"defaultbranch" variable will be used just as before.
Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
2022-02-17 09:26:46 -07:00
|
|
|
PARTS=`LANG=C svn info ${1} | ${GREP} URL | ${AWK} '{print $2;}' | ${SED} -e 's:^.*/svn/asterisk/::' | ${SED} -e 's:/: :g'`
|
2006-04-24 17:11:45 +00:00
|
|
|
BRANCH=0
|
|
|
|
TEAM=0
|
2007-02-21 14:07:43 +00:00
|
|
|
TAG=0
|
2012-06-06 17:22:11 +00:00
|
|
|
FEATURE=0
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2006-04-24 17:11:45 +00:00
|
|
|
REV=`svnversion -c ${1} | cut -d: -f2`
|
2007-05-22 20:26:35 +00:00
|
|
|
|
2009-03-12 01:00:29 +00:00
|
|
|
INTEGRATED=`LANG=C svn pg automerge-propname ${1}`
|
|
|
|
if [ -z "${INTEGRATED}" ] ; then
|
2009-03-12 01:33:04 +00:00
|
|
|
INTEGRATED=svnmerge-integrated
|
2009-03-12 01:00:29 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
BASE=`LANG=C svn pg ${INTEGRATED} ${1} | cut -d: -f1`
|
2007-12-10 09:00:44 +00:00
|
|
|
|
|
|
|
if [ "${PARTS}" = "trunk" ] ; then
|
2009-03-12 01:33:04 +00:00
|
|
|
echo SVN-trunk-r${REV}
|
|
|
|
exit 0
|
2006-04-24 17:11:45 +00:00
|
|
|
fi
|
2007-12-10 09:00:44 +00:00
|
|
|
|
|
|
|
for PART in $PARTS ; do
|
2009-03-12 01:33:04 +00:00
|
|
|
if [ ${TAG} != 0 ] ; then
|
|
|
|
if [ "${PART}" = "autotag_for_be" ] ; then
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
if [ "${PART}" = "autotag_for_sx00i" ] ; then
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
RESULT="${PART}"
|
|
|
|
break
|
|
|
|
fi
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2009-03-12 01:33:04 +00:00
|
|
|
if [ ${BRANCH} != 0 ] ; then
|
2012-10-18 20:13:17 +00:00
|
|
|
RESULT="${RESULT}-${PART}"
|
2012-06-06 17:22:11 +00:00
|
|
|
if [ ${FEATURE} != 0 ] ; then
|
|
|
|
RESULT="${RESULT}-${FEATURE_NAME}"
|
|
|
|
fi
|
2009-03-12 01:33:04 +00:00
|
|
|
break
|
|
|
|
fi
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2009-03-12 01:33:04 +00:00
|
|
|
if [ ${TEAM} != 0 ] ; then
|
|
|
|
if [ -z "${RESULT}" ] ; then
|
|
|
|
RESULT="${PART}"
|
|
|
|
else
|
|
|
|
RESULT="${RESULT}-${PART}"
|
|
|
|
fi
|
|
|
|
continue
|
|
|
|
fi
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2012-06-06 17:22:11 +00:00
|
|
|
if [ "${PART}" = "certified" ] ; then
|
|
|
|
FEATURE=1
|
|
|
|
FEATURE_NAME="cert"
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
|
2009-03-12 01:33:04 +00:00
|
|
|
if [ "${PART}" = "branches" ] ; then
|
|
|
|
BRANCH=1
|
|
|
|
RESULT="branch"
|
|
|
|
continue
|
|
|
|
fi
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2009-03-12 01:33:04 +00:00
|
|
|
if [ "${PART}" = "tags" ] ; then
|
|
|
|
TAG=1
|
|
|
|
continue
|
|
|
|
fi
|
2007-12-10 09:00:44 +00:00
|
|
|
|
2009-03-12 01:33:04 +00:00
|
|
|
if [ "${PART}" = "team" ] ; then
|
|
|
|
TEAM=1
|
|
|
|
continue
|
|
|
|
fi
|
2006-04-24 17:11:45 +00:00
|
|
|
done
|
2007-12-10 09:00:44 +00:00
|
|
|
|
|
|
|
if [ ${TAG} != 0 ] ; then
|
2009-03-12 01:33:04 +00:00
|
|
|
echo ${RESULT}
|
2007-12-10 09:00:44 +00:00
|
|
|
else
|
2009-03-12 01:33:04 +00:00
|
|
|
echo SVN-${RESULT}-r${REV}${BASE:+-${BASE}}
|
2007-02-21 14:07:43 +00:00
|
|
|
fi
|
2012-10-18 20:13:17 +00:00
|
|
|
elif [ -d ${1}/.git ]; then
|
|
|
|
if [ -z ${GIT} ]; then
|
|
|
|
GIT="git"
|
|
|
|
fi
|
2017-12-22 09:23:22 -05:00
|
|
|
|
2012-10-18 20:13:17 +00:00
|
|
|
if ! command -v ${GIT} >/dev/null 2>&1; then
|
|
|
|
echo "UNKNOWN__and_probably_unsupported"
|
|
|
|
exit 1
|
|
|
|
fi
|
build: Refactor the earlier "basebranch" commit
Recap from earlier commit: If you have a development branch for a
major project that will receive gerrit reviews it'll probably be
named something like "development/16/newproject" or a work branch
based on that "development" branch. That will necessitate
setting "defaultbranch=development/16/newproject" in .gitreview.
The make_version script uses that variable to construct the
asterisk version however, which results in versions
like "GIT-development/16/newproject-ee582a8c7b" which is probably
not what you want. It also constructs the URLs for downloading
external modules with that version, which will fail.
Fast-forward:
The earlier attempt at adding a "basebranch" variable to
.gitreview didn't work out too well in practice because changes
were made to .gitreview, which is a checked-in file. So, if
you wanted to rebase your work branch on the base branch, rebase
would attempt to overwrite your .gitreview with the one from
the base branch and complain about a conflict.
This is a slighltly different approach that adds three methods to
determine the mainline branch:
1. --- MAINLINE_BRANCH from the environment
If MAINLINE_BRANCH is already set in the environment, that will
be used. This is primarily for the Jenkins jobs.
2. --- .develvars
Instead of storing the basebranch in .gitreview, it can now be
stored in a non-checked-in ".develvars" file and keyed by the
current branch. So, if you were working on a branch named
"new-feature-work" based on "development/16/new-feature" and wanted
to push to that branch in Gerrit but wanted to pull the external
modules for 16, you'd create the following .develvars file:
[branch "new-feature-work"]
mainline-branch = 16
The .gitreview file would still look like:
[gerrit]
defaultbranch=development/16/new-feature
...which would cause any reviews pushed from "new-feature-work" to
go to the "development/16/new-feature" branch in Gerrit.
The key is that the .develvars file is NEVER checked in (it's been
added to .gitignore).
3. --- Well Known Development Branch
If you're actually working in a branch named like
"development/<mainline_branch>/some-feature", the mainline branch
will be parsed from it.
4. --- .gitreview
If none of the earlier conditions exist, the .gitreview
"defaultbranch" variable will be used just as before.
Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
2022-02-17 09:26:46 -07:00
|
|
|
cd ${1}
|
2017-12-22 09:23:22 -05:00
|
|
|
|
2012-10-18 20:13:17 +00:00
|
|
|
# If the first log commit messages indicates that this is checked into
|
|
|
|
# subversion, we'll just use the SVN- form of the revision.
|
|
|
|
MODIFIED=""
|
build: Refactor the earlier "basebranch" commit
Recap from earlier commit: If you have a development branch for a
major project that will receive gerrit reviews it'll probably be
named something like "development/16/newproject" or a work branch
based on that "development" branch. That will necessitate
setting "defaultbranch=development/16/newproject" in .gitreview.
The make_version script uses that variable to construct the
asterisk version however, which results in versions
like "GIT-development/16/newproject-ee582a8c7b" which is probably
not what you want. It also constructs the URLs for downloading
external modules with that version, which will fail.
Fast-forward:
The earlier attempt at adding a "basebranch" variable to
.gitreview didn't work out too well in practice because changes
were made to .gitreview, which is a checked-in file. So, if
you wanted to rebase your work branch on the base branch, rebase
would attempt to overwrite your .gitreview with the one from
the base branch and complain about a conflict.
This is a slighltly different approach that adds three methods to
determine the mainline branch:
1. --- MAINLINE_BRANCH from the environment
If MAINLINE_BRANCH is already set in the environment, that will
be used. This is primarily for the Jenkins jobs.
2. --- .develvars
Instead of storing the basebranch in .gitreview, it can now be
stored in a non-checked-in ".develvars" file and keyed by the
current branch. So, if you were working on a branch named
"new-feature-work" based on "development/16/new-feature" and wanted
to push to that branch in Gerrit but wanted to pull the external
modules for 16, you'd create the following .develvars file:
[branch "new-feature-work"]
mainline-branch = 16
The .gitreview file would still look like:
[gerrit]
defaultbranch=development/16/new-feature
...which would cause any reviews pushed from "new-feature-work" to
go to the "development/16/new-feature" branch in Gerrit.
The key is that the .develvars file is NEVER checked in (it's been
added to .gitignore).
3. --- Well Known Development Branch
If you're actually working in a branch named like
"development/<mainline_branch>/some-feature", the mainline branch
will be parsed from it.
4. --- .gitreview
If none of the earlier conditions exist, the .gitreview
"defaultbranch" variable will be used just as before.
Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
2022-02-17 09:26:46 -07:00
|
|
|
SVN_REV=`${GIT} log --pretty=full -1 | ${SED} -n '/git-svn-id:/ s/.*\@\([^ ]*\) .*/\1/p'`
|
2012-10-18 20:13:17 +00:00
|
|
|
if [ -z "$SVN_REV" ]; then
|
build: Refactor the earlier "basebranch" commit
Recap from earlier commit: If you have a development branch for a
major project that will receive gerrit reviews it'll probably be
named something like "development/16/newproject" or a work branch
based on that "development" branch. That will necessitate
setting "defaultbranch=development/16/newproject" in .gitreview.
The make_version script uses that variable to construct the
asterisk version however, which results in versions
like "GIT-development/16/newproject-ee582a8c7b" which is probably
not what you want. It also constructs the URLs for downloading
external modules with that version, which will fail.
Fast-forward:
The earlier attempt at adding a "basebranch" variable to
.gitreview didn't work out too well in practice because changes
were made to .gitreview, which is a checked-in file. So, if
you wanted to rebase your work branch on the base branch, rebase
would attempt to overwrite your .gitreview with the one from
the base branch and complain about a conflict.
This is a slighltly different approach that adds three methods to
determine the mainline branch:
1. --- MAINLINE_BRANCH from the environment
If MAINLINE_BRANCH is already set in the environment, that will
be used. This is primarily for the Jenkins jobs.
2. --- .develvars
Instead of storing the basebranch in .gitreview, it can now be
stored in a non-checked-in ".develvars" file and keyed by the
current branch. So, if you were working on a branch named
"new-feature-work" based on "development/16/new-feature" and wanted
to push to that branch in Gerrit but wanted to pull the external
modules for 16, you'd create the following .develvars file:
[branch "new-feature-work"]
mainline-branch = 16
The .gitreview file would still look like:
[gerrit]
defaultbranch=development/16/new-feature
...which would cause any reviews pushed from "new-feature-work" to
go to the "development/16/new-feature" branch in Gerrit.
The key is that the .develvars file is NEVER checked in (it's been
added to .gitignore).
3. --- Well Known Development Branch
If you're actually working in a branch named like
"development/<mainline_branch>/some-feature", the mainline branch
will be parsed from it.
4. --- .gitreview
If none of the earlier conditions exist, the .gitreview
"defaultbranch" variable will be used just as before.
Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
2022-02-17 09:26:46 -07:00
|
|
|
# If MAINLINE_BRANCH is already set in the environment, use it.
|
|
|
|
if [ -z "${MAINLINE_BRANCH}" ] ; then
|
|
|
|
# Try to retrieve MAINLINE_BRANCH from a local .develvars file first.
|
|
|
|
# .develvars is keyed by the branch name so we need to get that first.
|
|
|
|
BRANCH=$(${GIT} symbolic-ref --short HEAD)
|
|
|
|
if [ -f .develvars ] ; then
|
|
|
|
MAINLINE_BRANCH=$(${GIT} config -f .develvars --get branch.${BRANCH}.mainline-branch)
|
|
|
|
fi
|
|
|
|
|
|
|
|
# If we didn't find it, see if this is a well-known development branch.
|
|
|
|
# development/<mainline_branch>/<branchname> or
|
|
|
|
# devel/<mainline_branch>/<branchname>
|
|
|
|
if [ "x${MAINLINE_BRANCH}" = "x" ] ; then
|
|
|
|
MAINLINE_BRANCH=$(echo "${BRANCH}" | ${SED} -n -r -e "s@devel(opment)?/([0-9]+)/.+@\2@p")
|
|
|
|
fi
|
|
|
|
|
|
|
|
# If we didn't find it, get it from .gitreview defaultbranch.
|
|
|
|
if [ "x${MAINLINE_BRANCH}" = "x" ] ; then
|
|
|
|
MAINLINE_BRANCH=$(${GIT} config -f .gitreview --get gerrit.defaultbranch)
|
|
|
|
fi
|
2022-01-26 06:56:15 -07:00
|
|
|
fi
|
|
|
|
|
2015-04-13 09:54:18 -05:00
|
|
|
VERSION=`${GIT} describe --long --always --tags --dirty=M 2> /dev/null`
|
2012-10-18 20:13:17 +00:00
|
|
|
if [ $? -ne 0 ]; then
|
|
|
|
if [ "`${GIT} ls-files -m | wc -l`" != "0" ]; then
|
|
|
|
MODIFIED="M"
|
|
|
|
fi
|
|
|
|
# Some older versions of git do not support all the above
|
|
|
|
# options.
|
2015-04-13 09:54:18 -05:00
|
|
|
VERSION=`${GIT} rev-parse --short --verify HEAD`${MODIFIED}
|
2012-10-18 20:13:17 +00:00
|
|
|
fi
|
2015-04-13 09:54:18 -05:00
|
|
|
echo GIT-${MAINLINE_BRANCH}-${VERSION}
|
2012-10-18 20:13:17 +00:00
|
|
|
else
|
build: Refactor the earlier "basebranch" commit
Recap from earlier commit: If you have a development branch for a
major project that will receive gerrit reviews it'll probably be
named something like "development/16/newproject" or a work branch
based on that "development" branch. That will necessitate
setting "defaultbranch=development/16/newproject" in .gitreview.
The make_version script uses that variable to construct the
asterisk version however, which results in versions
like "GIT-development/16/newproject-ee582a8c7b" which is probably
not what you want. It also constructs the URLs for downloading
external modules with that version, which will fail.
Fast-forward:
The earlier attempt at adding a "basebranch" variable to
.gitreview didn't work out too well in practice because changes
were made to .gitreview, which is a checked-in file. So, if
you wanted to rebase your work branch on the base branch, rebase
would attempt to overwrite your .gitreview with the one from
the base branch and complain about a conflict.
This is a slighltly different approach that adds three methods to
determine the mainline branch:
1. --- MAINLINE_BRANCH from the environment
If MAINLINE_BRANCH is already set in the environment, that will
be used. This is primarily for the Jenkins jobs.
2. --- .develvars
Instead of storing the basebranch in .gitreview, it can now be
stored in a non-checked-in ".develvars" file and keyed by the
current branch. So, if you were working on a branch named
"new-feature-work" based on "development/16/new-feature" and wanted
to push to that branch in Gerrit but wanted to pull the external
modules for 16, you'd create the following .develvars file:
[branch "new-feature-work"]
mainline-branch = 16
The .gitreview file would still look like:
[gerrit]
defaultbranch=development/16/new-feature
...which would cause any reviews pushed from "new-feature-work" to
go to the "development/16/new-feature" branch in Gerrit.
The key is that the .develvars file is NEVER checked in (it's been
added to .gitignore).
3. --- Well Known Development Branch
If you're actually working in a branch named like
"development/<mainline_branch>/some-feature", the mainline branch
will be parsed from it.
4. --- .gitreview
If none of the earlier conditions exist, the .gitreview
"defaultbranch" variable will be used just as before.
Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
2022-02-17 09:26:46 -07:00
|
|
|
PARTS=`LANG=C ${GIT} log --pretty=full | ${GREP} -F "git-svn-id:" | head -1 | ${AWK} '{print $2;}' | ${SED} -e s:^.*/svn/$2/:: | ${SED} -e 's:/: :g' | ${SED} -e 's/@.*$//g'`
|
2012-10-18 20:13:17 +00:00
|
|
|
BRANCH=0
|
|
|
|
TEAM=0
|
|
|
|
TAG=0
|
|
|
|
FEATURE=0
|
|
|
|
|
|
|
|
if [ "`${GIT} ls-files -m | wc -l`" != "0" ]; then
|
|
|
|
MODIFIED="M"
|
|
|
|
fi
|
|
|
|
|
|
|
|
for PART in $PARTS ; do
|
|
|
|
if [ ${TAG} != 0 ] ; then
|
|
|
|
if [ "${PART}" = "autotag_for_be" ] ; then
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
if [ "${PART}" = "autotag_for_sx00i" ] ; then
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
RESULT="${PART}"
|
|
|
|
break
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ ${BRANCH} != 0 ] ; then
|
|
|
|
RESULT="${RESULT}-${PART}"
|
|
|
|
if [ ${FEATURE} != 0 ] ; then
|
|
|
|
RESULT="${RESULT}-${FEATURE_NAME}"
|
|
|
|
fi
|
|
|
|
break
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ ${TEAM} != 0 ] ; then
|
|
|
|
if [ -z "${RESULT}" ] ; then
|
|
|
|
RESULT="${PART}"
|
|
|
|
else
|
|
|
|
RESULT="${RESULT}-${PART}"
|
|
|
|
fi
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ "${PART}" = "certified" ] ; then
|
|
|
|
FEATURE=1
|
|
|
|
FEATURE_NAME="cert"
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ "${PART}" = "branches" ] ; then
|
|
|
|
BRANCH=1
|
|
|
|
RESULT="branch"
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ "${PART}" = "tags" ] ; then
|
|
|
|
TAG=1
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ "${PART}" = "team" ] ; then
|
|
|
|
TEAM=1
|
|
|
|
continue
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ "${PART}" = "trunk" ]; then
|
|
|
|
echo SVN-trunk-r${SVN_REV}${MODIFIED}
|
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
|
|
|
|
if [ ${TAG} != 0 ] ; then
|
|
|
|
echo ${RESULT}
|
|
|
|
else
|
|
|
|
echo SVN-${RESULT##-}-r${SVN_REV}${MODIFIED}
|
|
|
|
fi
|
|
|
|
fi
|
2008-08-05 15:30:23 +00:00
|
|
|
else
|
2009-03-12 01:33:04 +00:00
|
|
|
echo "UNKNOWN__and_probably_unsupported"
|
2006-04-24 17:11:45 +00:00
|
|
|
fi
|