Resolving ### files, locks up client for 15 minutes

[AngelaTseng]

Every once in a while, the Vault Client V3.0.1 will lock up for 15 minutes, and the status bar says "Resolving 725 files". Eventually it will come back and attempt to perform all the actions that were queued up. If I kill it and restart, it is fine.

This appears to happen if I wipe my working directory by hand and perform a Get through the command line, although I am not sure if this is the root cause.

[jeremy_sg]

Your command line fetch probably has -destpath set. This tells the command line client to not set up working folder information for this get. The GUI client is resolving the files in the working folder by setting the baseline files. Try this without the -destpath on the CLC get, and you shouldn't see any more resolving messages.

[AngelaTseng]

Thanks, I did have the -destpath set, but have since removed it thinking it caused other problems. On our build machine we have 2 "working" directories, one for CruiseControl .NET and the other for our clean nightly build. We tried to use the -destpath to easily switch destinations in our NAnt build, but quickly found problems with that approach. First, we couldn't check out the version file to automatically update during the nightly build, so we ended up setting up a user with the nightly build destination as the working folder. I suppose we could simply set the working folder each time to be certain of the destination (this option may not have been available in V2.6?). We also ran into the renegade status after using -destpath.

Anyway, the -destpath option has burned us more than once for a seemingly useful option.

[jeremy_sg]

It has its uses as long as your build never needs to do any checkins. You can always use the CLC setworkingfolder and unsetworkingfolder commands in your build scripts to make sure that files are going where you expect them to.