PRB: Undo Check Out Not Behaving As Expected

Last reviewed: May 22, 1997
Article ID: Q168844
The information in this article applies to:
  • Microsoft Visual SourceSafe, 16-bit and 32-bit, for Windows, version 4.0
  • Microsoft Visual SourceSafe, 32-bit, for Windows, version 5.0

SYMPTOMS

The "Undo Check Out" command does not operate as expected if you have the "Compare Files By" option set to "Time" and the "Set Date/Time on Local Files" set to "Current".

CAUSE

When you set "Compare Files By" to "Time", the algorithm used to determine whether a Get should be performed is based on a comparison between the timestamp on the local copy of the file and the timestamp on the last check in for the file.

If the timestamp on the last check in is more recent than the timestamp on the local file, SourceSafe does the Get and overwrites the local copy of the file. If the timestamp on the local file is more recent than the timestamp on the last check in, SourceSafe does not do the Get, and the local file is not replaced.

RESOLUTION

  • Set the "Compare Files By" option to "CheckSum" instead of "Time"

-or-
  • Remove the local copy of the file, and then perform the Get/Check Out.

STATUS

This behavior is by design.

MORE INFORMATION

If you perform an "Undo Check Out" with the above options set in SourceSafe, unexpected results occur.

Lets say that you've got a file checked out and you've edited it. The local file (the one you are editing) has a more recent timestamp on it than the last checked in copy of the file. After you've edited and saved the file you decide you really don't want the changes you made, so you go back to SourceSafe and perform an "Undo Check Out" on the file. You get the warning message stating that all your changes will be lost if you perform an Undo Check Out. You click "Yes" and SourceSafe does not copy the changes in the local file back to the server.

When you Get or Check Out the file again, SourceSafe sees that the timestamp on your local file is more recent than the timestamp on the last check in. SourceSafe does not perform the Get, and the local file is not replaced. As a result, you see all the changes you thought you had discarded instead of the unaltered copy you thought you retrieved by performing the Get.


Additional query words: 3.0b
Keywords : kbusage ssusage
Version : 4.0 5.0
Platform : WINDOWS
Issue type : kbprb


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: May 22, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.