Vault Command Line Client UNDOCHECKOUT throws exception

[tstafney]

v4.1.2.18185

I did some searching and found the following
http://support.sourcegear.com/viewtopic.php?t=7097
in the Gold Support forum. Seems to be the same issue. Not much of a resolution. And from a Google search I found this obscure file
http://support.sourcegear.com/files/vau ... rs_182.txt
which appears to contain (among other things) a very similar stack trace from a very similar cmd.

I am using the same scripts to build three different products and only this one product exhibits this error... and it seems somewhat random. I feel it may have to do with the number of items (as in >0 or 0) old or merged. I am continuing to run the script under various working folder states (as pertains to old, merged, etc) to see if I can capture the exact condition.

Anyway, here is the cmd and the stacktrace.

D:\builds\products\v1.3\DbrPlus>"C:\Program Files\SourceGear\Vault Client\vault" UNDOCHECKOUT $/products/v1.3/
DbrPlus
<vault>
<error>
<exception>System.NullReferenceException: Object reference not set to an instance of an object.
at VaultClientOperationsLib.WorkingFolderState_1.GetBaselineVersion(Int64 ID)
at VaultClientOperationsLib.WorkingFolder.GetBaselineVersion(VaultClientFile file)
at VaultClientOperationsLib.ClientInstance.UndoCheckOut(VaultClientFile[] files, LocalCopyType localCopy)
at VaultClientOperationsLib.ClientInstance.UndoCheckOut(VaultClientTreeObject[] objects, Boolean recursive,
LocalCopyType localCopy)
at VaultClientIntegrationLib.ServerOperations.ProcessCommandUndoCheckout(String[] objectPaths, Boolean recu
rsive, LocalCopyType localCopy)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)</exception>
</error>
<result>
<success>False</success>
</result>
</vault>

[jeremy_sg]

It looks like a case where you are undoing a checkout, which tries to revert to a baseline file. The exception is occurring because the baseline file isn't there anymore. Can you undo the checkout with the GUI client and choose to Leave the file?

[tstafney]

I do not believe this problem occurs in the GUI. This is done as part of the build process on our integration server. I am limited to CCNet, NAnt, Vault (via an nant Source Control Block) and the Vault Command Line Client (via NAnt exec task to commit changes upon successful build). As such "use the GUI" is not an acceptable solution.

I don't believe throwing a NullReferenceException is acceptable either. Perhaps a NoBaselineFileExistsException? NullReferenceException says "some developer didn't account for all possible values". At least an unhandled STRONGLY typed exception gives a guy some traction to investigate on his own

Anyway, I have a bit of a "6 one way, half a dozen the other" situation as it pertains to using CCNet and Vault to do our builds. We have a user set aside for continuous integration. So (using the default Vault Source Control Block for CCNet) here is the process:

• ccnet (via vault) checks for mods

• ccnet (via vault) gets lastest (with overwrite)

• ccnet launches nant

• nant, as the last step in the build, revs versioninfo(cs/vb) file(s)

• ccnet, via exec block, launches vault to COMMIT changes from previous step

• ccnet (via vault) labels the source branch (at a version just prior to COMMIT)

And here is what I think is the problem:
There is a sequence of operation a,b,c. The vault souce control block used by ccnet is performing ops "a" and "b". Shelling out using the vault command line client occurs as op "b". I believe this is resulting in some cache confusion on vaults part. Anyway, whatever the underlying issue, the appearance is that immediately following a build vault shows "Needs Merge" on the modified (but JUST committed) files. That is BAD because then subsequent builds do NOT have the proper versioninfo files. The crux of the issue is "why does vault think JUST committed (using -resolvemerge) files still Need Merge?"

Some solution attempts:

• use an undocheckout as a prebuild step (and that's how I got HERE).

• try using your "new and improved" vaultplugin for ccnet (Nope. That's how I got here:http://support.sourcegear.com/viewtopic.php?t=10502

Seems ccnet/vault integration is 95% complete via a couple of different routes. Each one has a failure point slightly different than the other. Dang, I hate that! Any help smoothing the bumps in the "get (with overwrite) BEFORE the build, commit files (with overwrite) DURING the build, label files (at version used by get) AFTER the build" would be GREATLY appreciated!

[jeremy_sg]

Obviously there are a lot of things going on here, and I need a higher level view of what you're doing. Please email support at sourcegear.com ATTN: jeremy with a link to this thread, and I'll call you.