Searching in Visual Studio allows me to set multiple search terms separated by a space in order to better narrow my results. This is helpful if you aren't sure if the name of the file is "ProjectXMLData" or "ProjectDataXML", but you know for sure it has Project and XML in the name.

Attached Images
- VSSearch01 - Shows searching for all 'project'
- VSSearch02 - Shows adding 'xml', but not as an exact match. The results are still displayed as expected
- WSSearch01 - Shows searching for 'project' and results show as expected
- WSSearch02 - Shows adding 'xml', but no results are returned

When it comes to text files, the embedded diff viewer is extremely helpful, allowing me to quickly click between files and see what changed. While it is possible to specify external tools for diffing non-text files, it is currently not possible to do so with the same ease of use or convenience. Embedded Diff and Custom Diff are currently mutually exclusive.

This request is to add an extensibility mechanism for the embedded diff viewer. I am thinking of this similarly to Windows' IFilter mechanism that allows custom preview renderers to be specified for any file type.

For example, if I wanted to diff a custom binary serialization that my company uses, I could write a program that converts it to text. Perhaps the program outputs the text to std-out, perhaps to a temp file - either way, Plastic would take that output and feed it into the standard text diffing feature. Similarly, it would make sense to provide the same functionality for images. In order to see diffs for 3MF files, I would specify a program that converts 3MF to BMP.

Currently, with "Move Changeset" I can only move to a new branch or an empty one.

But often I find myself quickly fixing a small bug or tweak a value, and switching to a different branch is something I don't think about at that moment. But the changeset does not belong on the branch that I committed it to.

It would save an incredible amount of time if "Move Changeset" would do the following, when selecting a non empty branch:
- Cherry Pick the full changeset from the target branch, including the comment
- Delete the changeset in question

Now I understand that deleting a changeset anywhere on a branch creates a sort of "Tower of Hanoi" challenge, of having to shelve all the commits on top of it, delete the changeset in question, and stack them back on. For now it would already be useful if I could do this with the latest changeset (no further dependencies).
But being able to delete changesets with dependencies (instead of messy reverse commits) would be very useful in it's own right.

Currently, when I'm on a branch and I want to merge what I have to another branch (e.g. main) I have to right-click on my current branch/changeset, select "merge from this [] to..." and then pick the target from an endless list of all my braches.

This is incredibly error-prone, but still somewhat faster and more convenient than switching to the target branch and then merging from the branch I've just been at.

What I'd like to see is when I right-click on another branch/changeset (that I'm not on) that I get the option "Merge to this branch/changeset...".

This might seem like a small improvement, but given how often we do this, it'd definitely help. An option setting to also then switch to the target branch when doing this might be a plus (I noticed someone else asked for this before).

Our usual workflow is to first merge from main to the current branch, sort out merge conflicts, check the build, etc., commit fixes and changes if needed, and then merge back to main.

Now, the update triggers only provide a path to the workspace being updated.
Having access to the old and new changeset-id's opens up quite a lot new possibilities.

For example, in UE4, when working with plugins in a code project, they are compiled automatically at first. When making code changes to the plugins, they are often not automatically detected which causes the engine to crash at startup.
Deleting two specific folders makes the engine recompile those binaries automatically and thus fixes this inconvenience. Unfortunately, this process takes about 5 minutes on average so doing it after every update is not feasible.
By providing a specific string/tag in the comment of checkins that require a compile, we are able to only recompile when necessary.

In order to make this work, we have to write out the current changeset-id to a file in the before-update trigger. Then in the after update trigger, we get the current one. Finally we would use the find command to get all changesets in between those two and check if any of their comments contain the tag.

We are already able to access the current changeset-id with
cm status --nochanges
and some parsing. (Although this could be made easier.)
Thus, only exposing the future changeset-id in before-update and the previous changeset-id in after-update would suffice.

Thanks in advance

In the branch explorer view you have essentially two sections. The graphical chart on the left and the properties panels on the right.

Assigning attributes to branches is very handy for keeping track of things like status and work type, but currently you can't see those attributes "in a big picture" as you have to click on the branch and then look at its attributes in the right hand panel.

What about allowing us a Display Option to draw the attribute name and value in the main chart right underneath the branch? This would allow for seeing the information on multiple branches at a glance and help with the big picture.

Some configuration files & libraries etc. can need to be present, but customized/recompiled per-developer.

We want to commit them to the repository (as they DO need to be present in at least a "default" state), but then once downloaded, we want developers to not have to worry about committing them ever. This feels like a very reasonable and common use case, and one for which "hidden_changes.conf" is made for.

However, when we switch branches/changelist (which is very often!), we get the following error-looking dialog for any files we are locally changing but that ARE in "hidden_changes.conf" (see image).

Ideally, if a file is in "hidden_changes" it wouldn't cause such an error and not put up any dialog. (e.g. I know it's a different use case but files that are cloaked don't put up a dialog) If there are any concerns about communication at the very least it should be a more friendly dialog such as "the following files are marked as HIDDEN CHANGES and have been changed and will NOT be updated to the new change list".

I often need to look up the history of a file, but I only care about its changes on the /main branch. From the regular history view, when the file got changed on a branch, it is unclear whether that branch made it back to /main or not. The current history view is fairly pointless because there is no way to tell which changes are relevant and which ones have been abandoned.

The 2D history view on the other hand is way too cluttered and cumbersome to navigate for any non-trivial project. Especially as it includes changesets where the file was merge from /main to another branch, which is exactly the opposite of what I want to know.

What I really want is a way to filter the regular history view to a single branch, but show all changeset affecting the file, including merges. The table format is good, I just need a way to filter out all the irrelevant changes that never made it back to /main.