This is a feature I noticed first in TFS-VC and found to be very useful. In our automated build process, we log all every operation, including Gets from the Source Code Control (SCC) database.
From time to time after a build has gone out either to QA or production, the question arises: what source files were used for building Release x.x.x? In those cases, it would be nice to go back to the build log file and see exactly which version of each file was pulled from SCC.
Of course, we also label our build, so we have this somewhat covered from that angle. But in SourceSafe, this was not always good enough because files could have been pinned to an earlier version and then pinning could have been updated after the build.
In any case, this would be a useful feature – especially with the –Verbose option.
Thanks.
Suggestion: Show version # for each file pulled during Get
Moderator: SourceGear
Our build process makes use of the command-line version of Vault. Logged output from Vault currently looks like:
I would like this file name to include the version number as follows:
with the number in parenthesis being the version number, or something along these lines.
Also note that we only label official builds (such as QA builds and potential release candidates). For example, nightly builds or developer test builds are not labeled (so as to avoid label pollution). In those cases in particular, it would be helpful to know what files were pulled for that build.
Code: Select all
<!-- Fetched $/Processor 6.2.5/Libraries/Library.StringTable/String.cs -->
<!-- Fetched $/Processor 6.2.5/Libraries/Library.StringTable/StringCollection.cs -->
<!-- Fetched $/Processor 6.2.5/Libraries/Library.StringTable/StringTableCollection.cs -->
…
Code: Select all
<!-- Fetched $/Processor 6.2.5/Libraries/Library.StringTable/String.cs (5) -->
<!-- Fetched $/Processor 6.2.5/Libraries/Library.StringTable/StringCollection.cs (18) -->
<!-- Fetched $/Processor 6.2.5/Libraries/Library.StringTable/StringTableCollection.cs (12) -->
…
Also note that we only label official builds (such as QA builds and potential release candidates). For example, nightly builds or developer test builds are not labeled (so as to avoid label pollution). In those cases in particular, it would be helpful to know what files were pulled for that build.