Problems with Undo check out for shared files.

[mbainbridge]

We have many files which are shared across 10's or even 100's of projects. If a file is checked out to a user, the only way (it seems) they can undo the checkout is to remember the project that it was checked-out from and undo the checkout from there.

For example, if I share $/TEST/FOLDER/test.c into $/TEST and check the file out of $/TEST/FOLDER, I can't then undo the checkout in $/TEST. In a simple example like this, it doesn't take much to work out where else to try, but when the file is scattered across dozens of projects, it can be a pain to resolve. (I know check-out files are listed in the pending change set, but when there's more than a couple of dozen files, it becomes difficult to find the one you want

I've verified this behaviour in 3.5.2 and Fortress 1.0, and both exhibit the same response (although we think this behaviour wasn't in 3.5.1). For the shared copy of the file, the Messages window displays "Undoing check out of file $/TEST/test.c" but it doesn't actually undo it. On another machine, Undo Check Out is actually greyed out.

[lbauer]

We did change the checkout behavior of shares in 3.5.2 in response to feature requests to make checkouts of shared files independent of each other (also pin operations, etc). This is the way VSS handles it.

But I can see where locating the file location may problem if you want to undo the checkout. I'll log a bug/feature request to make it easier to undo the checkout or find the file that's actually checked out.

[davenovak]

If the problem you're trying to solve is that you're looking to find the source location where a shared file was checked out, you can do that in 3.5.2 by:

• 1. Select any of the shared files that are checked out (from any location).
  2. Right-click on the file and pull up Properties....
  3. Go to the Check Out Status tab. The folder where this shared file was check out from will be shown here.

I hope this answers your question.

[mbainbridge]

In a normal environment, it probably would. However, we're using Vault in a way that Sourcegear probably wouldn't approve (for performance reasons... Our excuse is it's what we used on Sourcesafe, and there doesn't seem to be a better way to do it in Vault.)

We have a common source code library. Modules which have been tested and approved for release are checked out to user Librarian, and added to the library. This makes it easy to spot what's being worked on and what's safe to use elsewhere.

Unfortunately, this also means that Librarian's logon is used on several machines, with each developer having their own working directory location. It's the Vault, rather than PC, checkout folder which needs to be known to undo the check-out...