Marc S

Hi everyone. On the new UI, when trying to merge branches, you can't see much as the window is limited in size. So we can only see the start of the branches names, or their dates, but not both. There is also a lack of filtering. A filter exists but it requires the user to type something while in most cases, they just want to see the main branch and the branch with their last commit. So what's displayed is never what we need and never complete. This gets worse with every new branch added to the list. A better UX would allow to save the main branch as a favorite so it's always on top in the list while the other branches would be sorted by last changes dates. This way, both requires branches would be displayed on top at the same time and right away. A more advanced UX would add some options in the contextual menu when right clicking on a changeset : merge from main to this branch and merge to main from this branch. Main would be saved once as a favorite and then users would be able to make these common operations from that shortcut without clutter from all the branches. Considering these are most of our merges in my experience, this would save a lot of time. Thanks in advance.

Hi everyone. A common mistake I make is to think I'm on a branch while I'm on an other and checking a changeset. Sadly, there is no feature to fix that. It's not possible to copy that changeset into a shelve to remake it on the right branch and it's not possible to revert a changeset to local changes. I had to copy paste my code to the other branch from the diff window before deleting my bad changeset. Not an ideal solution when the initial mistake happen to users who are inexperienced or tired. This would be an easy fix with shelves, copying the changeset into one, committing it on the target branch and deleting the changeset (or if not possible, making a new changeset with the previous data). Thanks in advance.

Glad to see it was quickly added.

I fully agree. I'm not sure why we have multiple windows with some of them missing columns. They should all use the same model.

Hi. Today I've closed the "you're x version behind" notification multiple times as I was too busy to deal with it. Once my day is finished I thought about launcging that update now that I won't need to use Plastic but I have no idea where to trigger that. Adding an update shortcut in the top right menu would be convenient. Thanks

Interesting. i didn't have that issue but noted that some colors need work. I opened a thread about it : What else would you change?

I agree with @KristofMorva, the mix between Plastic and Unity is confusing. These are two different services and it doesn't make sense to have a version control interface on the game engine dashboard. As a veteran on both services, I have two different accounts created before the buyout and can't connect on Unity with the Plastic one. Please, keep them separated. Thanks

Fixed in today's update. Big thanks to the Plastic team for their responsiveness.

Hi. Using the new GUI alpha, I noticed that the date format have been switched to mmddyyyy and 12h clock some time these past weeks. The change seem to be unannounced as I can't find anything about it in the releases notes and there is no option to change it. What's worse is that some fields still display the ddmmyyyy format This is also affecting features like the one automatically adding the date and hours in comments meaning you'll store corrupted comments. Switch back to legacy is you're using that. Please set it back to ddmmyyy 24h format. Thanks.

That's the issue. There is a time gap between adding a new user and setting up their access rights. If you're interrupted or made a mistake, that user will have access to confidential information and you might never be aware of it. I'd rather have users ask for a permission I forgot to grant than users who can snoop in my data because I forgot something. For people dealing with projects under NDA, even seeing projects names can be a security breach. One solution to this is to create a new cloud for every project. This way, new users can't see anything else since they're only on one cloud. But to my knowledge, that's not possible from one account. And, more importantly, it could go against Plastic terms and conditions. I could have 60 teams of < 3 people all working on <5GB repos and never pay anything. I'm sure PlasticSCM's lawyers thought about it and that it could result in me being blaklisted. That said, if billing takes that into account, it might be an easy solution to this problem.

Glad to hear that. I can't wait to try it.

Hi. When switching branches with pending changes, we get a warning blocking us until we deal with said changes. This can be inconvenient because we sometimes don't want to commit those or need to move them to the other branch (if started working on the wrong one for example). The current solution to this is to shelve said changes and remember to unshelve them when getting back, or doing that to the destination branch. This could be automatically managed in the warning window. Instead of "OK", the user would have two options "Keep changes on that branch for later" or "Move changes to destination branch". The second option would have a warning if conflict. The first option would trigger a message when switching back to a saved branch "Would you like to re-aply your previously shelved changes?". Note that this feature already exists on competing services. This part of Plastic feels cumbersome when you're used to a more fluid workflow. Thanks in advance.

Hi. I'm using the format feature to color my branches and noticed that they aren't rendered with the chosen color. As you can see inside the white rectangle, the color comparison shows they are displayed darker. This makes the dark skin harder to read as colors don't pop as much. Note that the light skin and legacy GUI also modify colors, in the other direction this time, which also goes against contrast and readability. Dark skin should have light bright colors and vice versa. This is also true for the builtin colors : the green merge arrows for example are a slightly darker tint of their legacy counterpart. While readable, the current color scheme looks washed out instead of vivid. Built in colors should be flipped so they contrast with their background. Custom colors chosen by the users shouldn't be modified.

Thanks @calbzam. I saw it but have been too busy to risk trying it through command prompt. That said I'd be happy to try it as soon as there is a UI. A simple "right click on a branch -> Archive this branch" would be a very good start. Do you guys have that somewhere in the Alpha UI?

Anything new about this feature? I tried to optimize the space but it basically require not to use version control for heavy files which is obviously not a solution.

Can we have an ETA on this feature? I know it may seem like a detail but this is not just an aesthetic choice. Every other tools around cinema and video games are using a dark theme because it goes with the territory. A white interface like plastic may not be noticeable to you but for many of us it's like driving at night with a satnav that doesn't have a night theme.

Thanks @manu , I made it work. I was editing the wrong file (branchexplorer.cfg) instead of the file in the local workspace. For those who want to change it, you need to close plastic, change the line from false to true and start plastic again. It would if it was an option. ^^' I'd have done that two years ago if I knew how.

I tried it and it didn't work either. Even if it did, it wouldn't be a good solution as the people who need it the most are beginners who are also the least comfortable to edit .cfg files that could break the software.

I am but colors aren't as convivial as a face and would be better on branches. Plus the settings aren't shared between users which means you have to set them up on each computers. This could be very easy to add with a shared .conf file that would contain that data. username@company.com /plasticavatars/userpicture.jpg branchname #123456

Couldn't agree more. I initially thought "there must be a good reason for that choice" as I was a self taught user of version control with limited experience, and two years later, I'm still bothered by it. Even if there is an explanation, most beginners will be confused by it and will lose time searching for what they misunderstood.

Yes Yes, just make sure ignore.conf isn't confifured to ignore itself and everybody will have the same settings. Glad I could help.

I think he meant is that we traditionally have the branch hierarchy with a list like in the changeset tab. it's like having two halves of one feature. They should merge into one that would work horizontally or vertically with comments near their changeset. While we're at it, more colors and customization would help readability: having colors on branches and avatar pictures on changeset depending on their users would help a lot when working with a big team.

I don't think that's possible but that's a feature I'd support.

I'm not sure scene merging is supported. I've had it work tow years ago but I see a lot of people complaining about it. My advice is to use prefabs instead.

If you don't intend to commit these 30 files, you can tell Plastic to ignore them or their folder. If your project is properly set, you shouldn't see anything in the pending changes that isn't today's work in progress. Also, if check if your ingnore.conf file is shared between users. I think it isn't by default and could be more convenient when working with people who don't already master version control.