Jump to content

Marc S

Members
  • Posts

    46
  • Joined

  • Last visited

  • Days Won

    7

Marc S last won the day on May 16 2023

Marc S had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Marc S's Achievements

Apprentice

Apprentice (3/14)

  • Conversation Starter Rare
  • Reacting Well Rare
  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare

Recent Badges

13

Reputation

  1. 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.
  2. 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.
  3. Glad to see it was quickly added.
  4. 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.
  5. 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
  6. 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?
  7. 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
  8. Fixed in today's update. Big thanks to the Plastic team for their responsiveness.
  9. 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.
  10. 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.
  11. Glad to hear that. I can't wait to try it.
  12. 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.
  13. 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.
  14. 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?
  15. 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.
×
×
  • Create New...