cmtrc

We are using PlasticSCM as our VCS, where all of our interactions are done programmatically using cm commands (or, in some cases, the REST API). We are enforcing the exclusive checkout (locks) feature with the checkout-edit-checkin workflow. However, users are not directly interacting with the console, so we are running code that does this in the background as they interact with a GUI we have developed. When a user needs to see information about a branch, we want to list for them which of its files are locked and by whom. Thus, we need a programmatic way to determine what files are locked and by whom on any given branch, and we must be able to perform this operation outside of any workspace environment (this eliminates options like cm status and cm ls). We have tried cm lock ls, but the problem is that the returned information is insufficient. Each line is formatted like so: {Item GUID} {User Name} {Workspace Name} {Relative Filepath} Since we handle workspace creation and enforce that the workspace names are the same as repo names, we can say for our purposes that the third field gives us the repository name; however, we can't determine what branch the item belongs to. Performing potentially expensive operations/lookups to determine this by referencing the item's path/GUID is something we'd like to avoid; this would require us to first filter through all the results to the branch/repo we want, which leads to our next concern: we are unsure of the performance of cm lock ls and the subsequent filtering/search operations on a larger scale where there would be hundreds of repositories and thousands of files on the server. It would be nice to be able to perform a more focused search and/or obtain more information when using cm lock ls. There is an option to specify a revision object spec, but we are unable to find a way to wildcard this parameter in such a way to return files within only one specific repository or branch spec; instead, it will search the file path wildcard across all repositories in the server, ignoring whatever repo/branch object spec we give. Here is an example of a wildcard we tried that has this behavior: cm lock ls rev:/*#br:main@test_repo So we have two questions we are hoping to find answers for: Are we missing something with the cm lock ls command that would actually solve our specificity and performance concerns? Is there an entirely different way to get information about what files are locked by whom -- perhaps some server functionality or another cm command that we are missing?