Jump to content

JEP

Members
  • Posts

    61
  • Joined

  • Last visited

  • Days Won

    2

JEP last won the day on May 23 2022

JEP had the most liked content!

Recent Profile Visitors

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

JEP's Achievements

Rookie

Rookie (2/14)

  • Conversation Starter Rare
  • One Year In Rare
  • First Post Rare
  • Collaborator Rare
  • Week One Done Rare

Recent Badges

5

Reputation

  1. You really should be able to decide in every view that gives you a preview/diff whether they're on the right/left/bottom/top. But that's a whole other matter.
  2. Overall, I like the new GUI. But the one thing I really just hate is the history view. It went from a very readable column-formatted version to a "pretty" version that destroys the ability to easily go down vertically and mentally parse what you're seeing. This kind of format is just never the answer for readability. Plus, there's just not information here. You can't see the date/time. Only some "pretty" formatted date that's fine for social media posts but terrible for looking at files that might have multiple revisions on a single day. If you actually want to see the full timestamp, you have to click on every single one of the entries and look in the details. Forget about comparing a few at the same time, because that information just isn't there anymore. Likewise, you can't see changesets without clicking details. I can't have a conversation that says "well, if you look on 1345 it says _____ but 1346 says _______. I wonder if in 1344 if we _______." Now that branch and user are buried in the "pretty" subtitle, it's much harder to scan across and see the files being checked into each branch by each person. It's just very much a form over function decision, and I don't see how it was ever approved to be in the final GUI. It doesn't add anything but takes several things away. I'll still be using the legacy GUI simply because of this one area. And when the Legacy GUI is taken away, I'll be sticking on the last version that has it as long as possible. Please please please rethink this design.
  3. Release version : 10.0.16.6307 OS: Windows/MacOS/Linux : Windows Steps to reproduce : Right-click on a file in workspace explorer or pending changes and click History. Right-click on an older version and select "Revert to this revision". Real result : This shows the path as "e:\dev\cockpit\ssets\Scenes\CRJ200Scene.unity" when it should be "e:\dev\cockpit\ssets\Scenes\CRJ200Scene.unity". Note the missing "A" in "Assets". If you click Yes, you then get this error because of the incorrect path: Expected result : This should have worked normally, reverting the file.
  4. If Plastic would give users an option to move deleted files to the recycle bin rather than permanently deleting them, it would really save our bacon sometimes. I managed to find two uservoice requests on this: https://plasticscm.uservoice.com/forums/15467-general/suggestions/8214330-use-dustbin-for-delete-operations https://plasticscm.uservoice.com/forums/15467-general/suggestions/11356815-use-the-recycle-bin-whenever-you-can The first one was closed because it hadn't gotten enough votes in a year. The second one was closed within a week because it had been asked before. Which is frustrating, because this seems to shut it down from ever being a feature in the future, no matter how many people might want it. Personally, I ran into this just this week. I'd been fighting with Plastic issues all day (having some sort of network problem only with Plastic, which I talked to support about). In this hectic day, I accidentally deleted a folder that contained all the changes I'd been working on in the last day. If Plastic could have put them in the recycle bin instead, it would have saved me a couple of hours of work reconstructing them. I know that Pablo posted on one of those requests: I get that. Usually on the filesystem I do the same thing. But I don't find the same to be the case for when I delete things in a tool like Plastic, Unity, Visual Studio, etc. If I delete a file in those, it was probably a pretty important file, not just some random download or whatever. It's high value. That's why of those three I mentioned, all but Plastic delete to the recycle bin. It's especially frustrating when using a tool like version control, which is something that's all about not losing your valuable work. I'm posting this here rather than uservoice because it feels like it'll just get instantly closed like the last one, and some people might want to weigh in on it when they do a google search in the years to come (google searches don't seem to index uservoice properly, missing one of those links above) to see why Plastic doesn't do this. I get it if you don't want it to be the default (though that would help save more people). But at least give us the option. I keep seeing so many Plastic updates with changes that in no way add any value for our team. Not saying they don't add value for someone, but it would be nice to see something I'd actually use. And from a programming standpoint, it seems a pretty straightforward and unchallenging task.
  5. We stopped using the plugin long ago. Part of the problem being that it would checkout prefabs/scenes. So plastic must be doing it automatically on merges. I would love to turn that off, because it's a flow we don't use and just causes problems.
  6. I get that. But whether a file has actually been changed is an incredibly important part of version control (and a programmer's sanity). Thus masking that information is terrible. The other problem is that no one on our team actually uses the Check out feature. Plastic just decides to check out files for us on its whims. If there is some way to tell it never to do that, I'd love it.
  7. There are some things about checkouts that really mess up our programmers. I do understand what a checkout is (though it's not a big part of our workflow, since each programmer tends to have their own branch for a task). Say I have two files. I checkout both ScriptA.cs and ScriptB.cs. Then I change ScriptA.cs. The pending changes display in plastic is: ScriptA Checked-out ScriptB Checked-out It is baffling to me why you can't easily tell which script has actually been changed. It seems like the display should be: ScriptA Changed ScriptB Checked-out or ScriptA Changed / Checked-out ScriptB Checked-out This is much more useful. Why not show it this way? And that "Show checkouts" option in the first tab is very confusing. It explains that checkouts are shown always because they're just on a list. I expect that unchecking the "Show checkouts" will removed unchanged checkouts from the pending changes. But no, it removes all checkouts, whether they are changed or not. I can't even fathom when that's useful. I'd rather be able to have it just show me what's changed that's actually changed when I'm looking at pending changes. This kind of thing frustrates us to no end, and I have to tell our new hires "I know it's weird. That's just how Plastic does it."
  8. I really wish this was a feature that was built into Plastic. This is a lot of hassle (including ongoing hassle for each new developer) for something that seems like a very basic quality of life feature. I feel like the plastic developers may be overlooking how annoying it is because they spend over 90% of their time working on plastic, and so going through this hassle isn't as big a deal for them. But for those of us who are spending less than 5% of our time in plastic and just trying to work on our code, it's more annoying. If nothing else, I wish you could just filter out branches that haven't had a changeset in a certain amount of time, just like you can filter out changesets on the changesets tab.
  9. Correct, the button works. I use the support email all the time. It's just not always the best form for a bug report, as it being public really helps other people find it so they don't spend their effort duplicating it. And so they can see any workaround posted. You just have some mixed messaging out there on how to report them.
  10. Merged from one branch to another. The merge tool popped up and I clicked on the Resolve button to accept the automatic merge suggestion. The button then changed to "MarkAsUnresolvedButton". On a related note, according to https://www.plasticscm.com/support this is where we're supposed to report bugs. But there is no Bug subforum. Perhaps it's because you know some people will just report them anywhere. I also ran across this https://plasticscmsupport.zendesk.com/hc/en-us which seems to be defunct but still comes up when googling for where to report plastic scm bugs.
  11. I don't really have time to record and upload/email a video. I'm just right-clicking on a file under "File changes in conflict" in a merge: That's the menu I mean. I select on those options, but then it refreshes after a little and resets it.
  12. The Incoming Changes view auto-refreshes very frequently, erasing any choice for "Select merge contributor". This is incredibly frustrating. Is there any way to change this? If not, please make it where you can either turn off the auto-refresh for it, or even better where the auto-refresh doesn't erase your changes for an object that was already there before and after the refresh.
  13. Really looking forward to a true dark theme. Just switched today and was disappointed by the main areas of interest still being bright.
  14. One thing I wanted to drop into this thread since it's a hit that comes up in google: check to see if you have any files in your ignore/hidden.conf that aren't being shown. If they are, these files aren't being selected for checkin/undo changes, and the operation will fail. On Pending Changes, there is an Options button. Under What To Show, you can select Show ignored and Show hidden. This can help dig yourself out of this hole. I really do think the UI should handle this way better.
×
×
  • Create New...