-
Bug
-
Resolution: Unresolved
-
Major
-
None
As part of our build process, a custom task uses the values of SVN_URL_n and SVN_REVISION_n to tag the modules used in the build, it appears however that the value of SVN_REVISION_n matches the "last change revision" (per "svn info") of the SVN_URL_n, but this may not be the latest revision of the directory itself in the case when the location is a branch. This causes issues when modules are pulled from a branch, and the branched location has not had any commits to it after the branch was made. E.g.:
- http://repo/trunk/a.module contains one file, checked in at revision 100
- http://repo/trunk/a.module is branched to http://repo/branches/test-branch/a.module as revision 200
If a build is configured to pull a.module from the branch "test-branch" created above, the associated SVN_REVISION_n (assuming that a.module is unchanged on the branch) will be "100" - the last changed revision of the contents.
As the branch itself didn't exist at revision 100, the revision from the environment variable cannot be used to perform tagging on the module using "svn copy":
svn copy -r100 http://repo/branches/test-branch/a.module http://repo/tags/build-xxx/a.module
Results in an error (as "a.module" did not exist in test-branch at revision 100):
svn: E160013: '/branches/test-branch/a.module' path not found
Is there a reason that the revision number in the environment variable only takes into account the revisions of the contents of module location, and not the latest revision of the module location itself?