Eric Carter

After setting up a new workspace, gluon should open the configure workspace dialog immediately, instead of leaving you with an empty workspace. Empty workspaces don't do anything, and it's one more step that needs to be explained to artists before they can start working. It would be much simpler if it just prompted the user to pick the folders that they were interested in.

The tooltip on the Changeset panel describes them as "integers": But the changeset panel itself describes them as "Name": But the Branch Explorer calls them "Object Name": But the workspace explorer refers to them as "Changeset": The name for this number should be more consistently referred to. The clearest term to me would be "Changeset ID", which would clarify phrases like "My changes are in Changeset 9" clear, as well as the abbreviated form "cs:9".

In various places, including the Pending Changes dialog "checkin" and "check in" are used incorrectly. The act of checking in changes is "check in", and result of checking in changes (synonymous with changeset in Plastic) is a "check-in". "Checkin", which is synonymous with "check-in" is frowned upon in some circles but is growing enough in usage that I would not consider it explicitly wrong. However, it is never correct to use it in place of the verb phrase "check in".

Using "src" and "dst" abbreviations on these buttons in the Sync To Cloud panel isn't a good tradeoff for space. Even as an experienced source control user, "dst" isn't clear to me. Is it distributed? Destination? For non-english coders "src" could easily be confused as either Source or Service. Spare a few vowels and make these buttons more explicit about what they do.

This tip is a mix of "The Basics of Source Control" and very technical terminology that will be lost on the audience. Someone who doesn't know what a changeset is also probably doesn't know these terms either: integer repo guid replication The second tip also explains that new repos have something called a "changeset zero", but even as a very experienced source control user, I don't understand the significance of this tip. Add at least a phrase explaining why this is significant, or why I should remember it. I think it's helpful to include the definition of "csets" in this tooltip so usages of that nickname are accessible, but I would avoid using "csets" in tips like this, since it's one more thing a new user has to learn before the tooltip is useful to them, and they may or may not have learned that term before coming to other tooltips.

Hmmm... that page describes the process for subtractive merging, but doesn't actually say how to do a subtractive merge? I'm also worried that this is getting a lot more complicated than I'd like it to be. In Perforce or Git, I right click a changeset, pick the rollback option, and submit and I'm done. How many subtractive merge operations do I need to do to roll back 4 changesets? This page says that it's possible to remove changesets: https://www.plasticscm.com/book/#_delete_empty_branches_only Removing changesets 5 thru 9 seems simpler, and will leave me with a cleaner history. How do I do that? (Again, the page in the book doesn't explain how to actually do the thing it describes).

It's a mix of all those things, but I think the grid layout is inescapably wandersome. With a grid layout there's no way I can read it like a list, top to bottom or left to right and find what I need. The icons just add extra space to the already scattered grid layout. Grids are great if the icons are expressive enough or familiar enough that you don't need the words, you can just hone in via a color/shape/details heirarchy. But in Plastic, with a list of complex abstract actions, many of which are only rarely used, I'm always going to be relying on the words, which means I need to do a lot of reading, which means list are a lot better of an arrangement.

No, no, this is not confusing at all. I understand perfectly what you're describing, but you're answering a different question than I'm asking. You're describing how I can make my local workspace match the state of changeset 4. What I'm asking is how do I generate an changeset which is the inverse of changes 5 through 9, that when committed, will leave the remote repository's contents bitwise equal to the state it was in in changeset 4. I am attempting to generate changeset 10, a change which removes all the changes in changesets 5 through 9. Whether my local workspace is pointed at changeset 4, 5, 9, or 10 after I am done isn't important.

I understand the differences between those 3 actions. But check this out: I can get the History of my entire depo by selecting View History on the root: From here, I can select a diff and choose Revert: Now, this seems to be like a totally reasonable thing to express. I want to revert all files to the state they were in in version 3. The expected outcome of a naive user is unambiguous. In your post above you said that reverting the root node is not possible (presumably because of some technical restriction). So my first thought is: feature request, either make it so I can revert the root node like any other folder, or improve the flow in a way where you don't offer me this revert option that won't work. My second thought is: how do I actually do the thing I want? I need the tip of master to be the same as it was in revision 4. Update/Switch doesn't help me, because I'm not trying to get my local copy to revision 4, I'm trying to revert all the changes to all files that happened from revision 5, 6, 7, 8, 9, and 10. I want master to be the same as it was in revision 4. In other source control solutions I simply revert all files to their state in revision 4 and check in. In Plastic, I can't do that because the root node cannot be reverted. I'd have to go through item by item reverting every file individually.

Ok, so I think what you're saying is you CAN check in the ignore.conf file, and it will still work, but if you want to ignore files which are already checked in you have to use the hidden_changes.conf. But either way, ignore.conf still works perfectly fine regardless of whether ignore.config is checked in or not.

I think I have the same problem. Can you explain a little more what you mean? Are you saying ignore.conf doesn't work at all if it's checked in?

Thanks Carlos, If you can't revert from the History panel, why does it present you with that option? Is this a bug? It's super confusing. I wasted more than an hour trying to figure it out, and solved it by trashing my repo and starting over from scratch. After I switch my workspace via the branch explorer, there are no pending changes, nothing to check in. How do I make this code state the new tip of the branch? I am trying to revert all the changes after this one, so this state needs to get back into the repo somehow.

Updating my client to the latest revision, and making a new commit by adding a text file don't fix this problem. Gluon and Plastic SCM both have the same problem. Are there logs somewhere where I can get a more detailed error message?

To be clear, this prevents me from reverting to any revision in my history. They are all blocked by the same error.

Oh man, how I wish it could look as good as that Visio chart! The font choices there are SO much better than any of the images or the current UI. It's so much more legible! Like jwvanderbeck, I'm on a 4k monitor, and so many of the fonts are illegibly small faint scratchings. I'd be so happy to see fonts like that Visio chart, I'd actually be able to read everything at a glance! If nothing else comes over, please replicate those text changes exactly! The first thing I wonder about the fixed tabs is what happens when the tab bar is full enough that it needs to scroll? Are the pending changes stuck on the left, and my most recently opened History panel is on the far right, and I have scroll the entire bar left to right and back to use them both? If the tabs can be moved, I can put the main tabs in the context where I'm using them. I don't know if it's that big of a deal, but being able to unpin the main tabs an repin them when I want seems like a safer bet. I like the idea of switching to a New Tab picker for actions, but the layout seems a lot less readable. My eye has to bounce around between a bunch of abstract icons and small text scattered around the page. The old UI is a single list of text that I can skim down pretty quickly to find the name of things I'm looking for. If the next tab page had an equally skimmable layout, I'd be for it. As it stands, I'll switch back to the old way (even though I agree the new tab page method is better). The "Plastic SCM" category of the home screen is a much better example of a layout I'd like to see on the new tab page. If the goal of the Home panel is to reduce clutter/gore for new users, it feels like having a "News" section runs counter to this. That's some advanced user reading material right there, and it's super duper noisy. The "New" tags draw your eye away from the core use of the software, and the text density says that this should be the body of your work, not an exit to a web page.

Seems like a perfectly human answer to me?

I'm trying to revert my repository to revision 4, but every time I select a changest in the history and pick "Revert to revision" I get an error dialog that says "The root item can't be reverted". How do I get my old changes back?