Mark unknown revisions as such and fail instead of reporting revision 0.
Otherwise CTest reports massive file updates between revisions when the
server timeouts while trying to fetch the current revision number.
Instead of removing the depot name, which causes problems when looking
at the file change list in CDash, make the Update test remove a given
prefix from the files retrieved from Update.xml.
Teach the ctest_update implementation to use the p4 command-line
client to perform updates and extract the list of changes.
Add a CTest.UpdateP4 test like those that exist already for the other
version control tools. Make the test available when p4 and the p4d
server are found. During the test launch p4d in the background to
serve a repository from the test directory. Then direct the client
toward this server for the duration of the test.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
Generated Update.xml file is larger than the previously
hard-coded limit of 4096. Introduce variable max_update_xml_size
and bump it up to 16k for reliable test runs.
Use 'git fetch' followed by 'git reset' to update the source tree. This
is better than 'git pull' because it can handle a rewritten upstream
branch and does not leave local modifications. After fetch, parse
FETCH_HEAD to find the merge head that 'git pull' would choose to track
the upstream branch. Then reset to the selected head.
In the normal fast-forward case the behavior remains unchanged.
However, now local modifications and commits will be erased, and
upstream rewrites are handled smoothly. This ensures that the upstream
branch is tested as expected.
Teach (create|run)_dashboard_script macros to treat the argument as the
name of a build tree. Append '.cmake' to generate the dashboard script
name. This allows future re-use of the macros for multiple test
scripts.
Git does not automatically checkout the matching version of a submodule
when it checks out a new version of the parent project in the work tree.
If the submodule reference changed in the parent project then we were
reporting the submodule path as a local modification. Work around the
problem in ctest_update using "git submodule update" after "git pull".
For projects with no submodules this is a no-op. See issue #10662.
Also add a submodule to the test project for CTest.UpdateGIT to test the
work-around.
Commit "Teach CTest.Update tests to strongly check entries" (2010-02-09)
started checking Update.xml entries strongly. This revealed that some
cvs clients report "U CTestConfig.cmake" during update even though the
file did not change and it selects the same revision. As a result the
test fails with
Update.xml has extra unexpected entries:
Updated{CTestConfig.cmake}
We fix the test to tolerate this particular extra entry without failing.
Previously these tests just checked for matching file names in the
Update.xml files. Now we check the update types (Updated, Modified, or
Conflicting) and reject unexpected extra entries.
The commit "Submit Subversion directory path in Update.xml" added the
element <SVNPath>...</SVNPath> to Update.xml for Subversion work trees.
This commit teaches the CTest.UpdateSVN test to verify the presence of
the element.
We teach CTest to report in a <Revision> element the revision of the
source tree that was tested. This makes sense for all modern VCS tools
because they version the whole tree. We simply omit this element for
CVS because it only versions files. See issue #7541.
This creates new tests "CTest.UpdateSVN" and "CTest.UpdateCVS". They
test that the Update.xml produced by CTest for a version-controlled
project contains entries for files added, changed, and removed.