p4v-usability-issues.md

1. There should be a Client view tab in the main views of the workspace. There are three views in Perforce: Depot view (//depot/...), Client view (//clientspec/...), and Workspace view (X:...). However, there are only two tabs in P4V: Depot and Workspace, and neither of them are ideal for typical workflow. Users are probably most comfortable, organizationally, with the Workspace view because that is how the files are organized on their hard drive. This view is cluttered with local file system files (reinventing the native file browser behavior). A good Client view would be the best of both worlds: only show server-controlled files but organized as they are on the local drive.

2. Changelist description dialogs seperate the file name and file path into different columns. Have a way to show the full path with name of those files. Elipsize the paths if they are too long for the dialog, deduce a common root to relpath from, or make showing the path optional.

3. It's not possible to unshelve a +l file already opened and locked by another user. It used to be possible to open a file for edit without +l (stripping the +l flag in the pending changelist), but changing the +l flag now requires amendments to edit that P4V doesn't understand, and stripping +l in a changelist is prohibited if someone already owns the lock. This closed an exploit for revising a file open and locked by another workspace, but also further compilcates unshelve in this context. Anyway, unshelve should detect a +l file and sync to #0 that file (or better yet some functional equivalent with opened status so it shows up in changelists and isn't stomped by sync). Frequently unshelve is for a speculative change, and not for readying a file for submission.

4. Unshelving files that are shelved from another stream is only easy if those two streams are directly related. Frequently streams aren't directly related, and are in different depots. The current workaround is to make a branchspec to provide unshelve with views that map the shelved depot path to a depot path mapped to the workspace. Ideally this should be done on-the-fly (given that we know what depot path the shelved files are, and we know the current depot path because it's mapped into the current workspace). Better yet would be to interrogate the branching history so that unshelving files from different branches know which file to drop the changes onto (for cases like a re-rooted depot or renamed files).