I’ve had to use cm find removed a few times. It’s a shame it’s totally undocumented. The only hint of a documentation is this old post on the old Plastic forums. But it still leaves unanswered questions. I still can’t figure out how to do anything other than dump every single entry and then filter it. If I do
cm find “removed where Item=‘c:\workspace\filepath’” it always says 0 found (even when using the exact path that was found by doing cm find removed --format={Item}).
I think that this poor documentation is really giving UVC a degrading reputation in the community. Which is a shame, when there’s tools out there if only you have the secret knowledge.
Hi Jason, I forwarded your suggestion and feedback to our technical writer, and we will see how to include the example given in the legacy plastic forum into the new tech doc page on the Unity domain.
We appreciate your patience and your regular feedback, which helps us improve the UVCS documentation.
It will take time but know that this is one of our priority moving forward.
If you have some time, would you mind giving us your opinion on these 2 new pages available here?
Are they useful and complete, or do you think that something is missing?
1- Security guide
2- Security scenarios
Hi Jason, Regarding the specific command you were asking for, “cm find remove” is an internal command. That’s why it’s not documented (even though I can see it was shared in an old forum post).
I was able to make it work by filtering by item ID:
It’s a good start, I think. It does muddle up cloud vs on-premises servers a bit, I think. At least, I assume it’s only the on-premises servers that have the ALL USERS group, as the cloud does not. It isn’t always clear when it’s talking about one setup versus the other.
I think it would also help a very clear description about how repository server permissions, repo permissions, path permissions, the allow/deny on both, and the override setting on both interact. This is something that felt counterintuitive to me, even though I’ve been dealing with setting permissions on filesystems for decades. Just something about it (mostly the UI, I think) always throws me off and it’s just not immediately obvious. Of course, it would help if there was a button in the UI where you could see what the effective permission to a thing would be for a specific user. But failing that, clear documentation on how all those levels of permissions and setting interact would go a long way.
One thing that I feel was lacking in all the security documentation was that I could never find anything anywhere that actually covered all the permissions that show up in the box. A lot are easy to guess at in context, but to this day I don’t really know exactly what mergefrom controls, or the exact differences between read and view permissions. My ideal document would contain a section where each and every permission is listed an detailed.
And on a side note, I really hate that the DevOps dashboard and the UVC GUI client use the same word or similar words to mean different things:
In the latter, “Permissions” means repository server permissions. In the latter, “Permissions” means repository permissions. And “Repository permissions” and “Repository server permissions” are worded just closely enough that it’s easy to get thrown off when you swap between setting up permissions in the GUI and on the website.
They should really use unambiguous terms in both places: Repository Permissions and Repository Server Permissions.
You can get the item id by configuring the output format of the “cm ls --help” command. But this command requires you to enter the changeset id/branch (assuming the item was deleted, and it’s not on disk anymore).
Gluon GUI has a panel to show all the Deleted items. Is this useful for you?
The issue with using cm ls is that if I already knew the changeset id/branch where it existed, I could just browse repository on that changeset and view history on the file. At that point, I wouldn’t need to use cm find removed anymore.
The gluon panel is sort of helpful. I had known they had the panel but I hesitate to recommend that our people use it because they might start using that instead of the regular GUI. We don’t really want the support hassle that might result in. It’s been so many years that I’m surprised this has never been brought over to the regular GUI. It would have been a nice “here’s a good reason the new UI is better than the old one”!
The other issue is that when a folder is deleted, there’s no good way to see that one of its children have been deleted. So if you search for a specific filename, you may find no entries. But I think that’s a lot harder to solve as I’m pretty sure you don’t store that information in any kind of change history internal.
A “Deleted items” panel would be useful in the Plastic GUI. I’m sharing your feedback with the team, and please feel free to open this feature request.
