The release build is due to roll in an hour but it can't be done without a change to foo.cpp.
Which is checked out to Fred, who's inconsiderately taken the day off.
What will you do, what will you do?
Before foo.cpp can be checked out again, modified, and checked back in, Fred's sticky paws must be taken off the file.
Breaking file locks is not as straighforward as it might be. SourceSafe does not provide the administrator with override privileges. Instead, the following procedure must be followed.
Open ssadmin and change the password of the user 'fred' who has the file checked out to something e.g: 'temp'.
Open a command window and uncheckout foo.cpp by executing this sequence of entries
Enter ss undocheckout "$/Some/Project/Path/foo.cpp" -Yfred,temp
$/Some/Project/Path/foo.cpp was checked out from [Fred]
...., not from the current folder.
File "c:\foo.cpp" not found
c:\foo.cpp has changed. Undo check out and lose changes?(Y/N)
Open the SourceSafe client at the Project containing foo.cpp.
Previously, foo.cpp was high-lighted in red to indicate it was checked out to Fred.
It should now be highlighted in normal plain black text to indicate it is available to be checked out again.
You can now tell the team to check the file out, make the necessary fix and check it back in.
Send an email to Fred, to advise him that his SourceSafe password has been changed to 'temp', and
ask him to change it back to his usual password the next time he logs in.
You should also advise Fred that:
- The version of foo.cpp on his disc is now obsolete.
- If he has made changes then he should save his local copy before checking foo.cpp out again and over-writing his local version.
- It's up to him to merge his changes into the latest SourceSafe version.
Reference : Microsoft article Q123474 HOWTO Logon With a Name Other than the System Logon