Post
by sterwill » Fri Apr 16, 2004 2:35 pm
Killing the Vault client process should be OK. When you log back in, you'll notice that some of the files have had their checkouts undone, others will still be checked out. You can then undo the checkouts on these files and delete them from the repository.
A client optimization in Vault 2.0 tries to detect whether a "Modified" change set item is really modified by doing a CRC check. If the file is identical to the baseline version, the checkout will be undone (no new version will be created). Vault 2.0.0, 2.0.1, and 2.0.2 do this very slowly because they refresh the checkout list between each undo. Starting with 2.0.3, this will work much faster. This is what's causing your commit to take so long.
Undoing the checkouts of files that weren't really modified always occurs before the real transaction is begun. (Checkouts don't modify versioned file data, just locks, so they're not part of an atomic transaction.)
During the transaction part, after "Beginning transaction" appears in the messages pane, files are added or new versions are sent to the server. Aborting or killing the client then will cause the transaction to be aborted (no changes will happen on the server). This can be done anytime before the "Ending transaction" string appears in the messages pane, and your changes will be forgotten by the server. If "Ending transaction" appears, it's too late.
Killing the client after it has printed "Ending transaction" will not stop your changes from being committed. The server won't know the client has disappeared, since web services are "stateless" at the socket level, and will continue processing the transaction.
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`