Jump to content

Marc S

Members
  • Posts

    46
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by Marc S

  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.

    • Like 1
  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. 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

    image.png.3ba45c52f6440bbe855732a7fb7d7c19.png

    • Like 1
  4. On 11/11/2022 at 6:43 PM, tcz8 said:

    Here is my input:

    Getting rid of the rid of the tabs was a good idea, they were redundant.

    But I don't like how washed out the new UI is compared to the old one, and it's enough for me not to want to use it. I don't understand the trend of trying to make UI so uniforms, nothing stands out, it's like you are trying to kill all cues that made it easy to navigate visually. It's not so bad (I've seen a lot worse) but it's a step in the wrong direction.

    You need a "classic" theme.

    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?

     

  5. 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.

    On 11/16/2022 at 5:28 PM, ollieblanks said:

    You just need a Unity ID to access it.

    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

    • Like 2
  6. 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  image.png.9d59bd44a81c3778695ee9b156a8c105.png

    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.

  7. On 5/9/2022 at 11:00 AM, ollieblanks said:

    Adding the user to the Organization will grant them access to the everything by default.

    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.

  8. 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.

    image.png.d4957eb2add0c3147ee212cf286b0b8d.png

    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.

  9. 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.

    plastic.thumb.png.4a839521a46d43069898963b4875b75f.png

  10. 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?

  11. 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.

  12. 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.

    1 hour ago, manu said:

    We didn't make it a preference because it's not that common to change the arrow direction.

    It would if it was an option. ^^'

    I'd have done that two years ago if I knew how.

  13.  

    23 hours ago, calbzam said:

    I think this is the setting Pablo is refering:

     

    Regards,

    Carlos.

    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.

     

  14. 10 hours ago, calbzam said:

    I guess you are already aware of the changeset color by user feature, right?

    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

     

  15. 1 hour ago, MikeK said:

    And your arrows in the branch explorer are almost the blocker for me. I have read your explanation but I do not care if graphs are acyclic or not – I see the arrows as the dataflow and the fact that some of your arrows are the directions of the graph edges and the others (merges) are the dataflows hurts me nearly physically.

    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.

  16. 28 minutes ago, Gardenfiend Games said:

    Alright, I kind of understand what you're saying - so basically we shouldn't really be keeping any 'permanent' Private files? So if we don't want a file to be in the repo, I should instead add it to the ignore list?

    Yes

    28 minutes ago, Gardenfiend Games said:

    And if the project is set up correctly (ignore.conf), then when my teammates do some work and then go to Checkin, they should just be able to select all of the "Changed Items" as well as "Private and Added" files, and just push them all without having to look through the lists?

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

     

    29 minutes ago, Gardenfiend Games said:

    Thanks for the help, I've been trying to get a lot of upgrades to my project done over the holiday break so that I can have it all ready when my team comes back to work - so this is one of those things (switching from Collab to Plastic), and I'm getting pretty close to fully understanding it.

    Glad I could help. :D

    • Like 1
    • Thanks 1
  17. 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.

  18.  

    9 hours ago, Gardenfiend Games said:

    If I have 30 files that are actually supposed to be Private, and then I create 20 new files, I have to painstakingly go through the list and figure out which should be added.

    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.

    • Like 1
×
×
  • Create New...