Tilman

@ollieblanksthanks for reading through that wall of text. I'm afraid it will be another, but here it goes: This is the landing page if you enter plasticscm.com There is a video above, which has a 2 minute marketing video. I reject information that I have to watch a video for on a landing page. The video explains the per issue branching, but doesn't mention that this comes at the price of not being able to check in individual files due to the per changelist tracking, while it should present the benefits of this decision and offer a direct alternative on the spot without me having to figure it out the hard way. besides the table and video there is no information on the landing page. That's not good, but then there is the "Getting Started" guide here https://docs.plasticscm.com/labs/main with a point "Fundamental concepts of Plastic SCM" - and DAG and per changelist tracking is not even mentioned? At this point it almost seems as if this is actively trying to be hidden as sort of an ugly secret of what allows to make all these marketing promises. I guess it's rather just taking for granted though, and is just forgotten to bring up as something important. Most of your users will come from either git, perforce or svn, and all of them allow you to check in individual files. This leads to a workflow where you have multiple files checked out, and one by one check in something as soon it becomes ready, while others stay checked out. Which to me just became second nature, but is far from the plastic approach. And I think I am not alone in this being a negative surprise. Not that its not nice to be able to have thousands of branches and work on a branch per task basis - but if that comes at the cost of users coming from other platforms that are much older than plastic, not being able to work like they are used to, then it would be good to make that apparent in any way possible. I would expect for instance a row in that table: Per Changelist Tracking & DAG| (YES)[more info!] | (No) | (No) | (No) Then this "more info" would link to the getting started guide, where under the fundamental section you would explain why this switch to DAG was done, what this means for you as a perforce or git user, and why your workflow is better, and links to further documentation pages regarding DAG. ___ I've read/viewed through - a landing page - a getting started guide - a 2 minute marketing video - browsed the documentation for a long time trying to find anything extra - read an assay worth of this "How plastic views the world" book And didn't get any information that would have spared me running head first into the wall, adding two days of extra work into an already busy schedule, forcing me to work extra hours beyond anything anyone ever should work. It feels just unfair. The reality as in most cases will be though that your team has busy schedules too and is just accidentally being ignorant. I understand that. But this is a reoccurring issue, I am not the first to run into these troubles. In fact the only information on this issue in general I could find in the forums. Maybe you should create a system that allows you to track reoccurring issues in forums better, otherwise you are just binding resources in answering the same questions again and again, and have your users run into experiences like I had. Oh, I also watched 10 minutes of a video that was older than DAG with a pre win10 windows, that of course didn't tell me anything about DAG. I complained on that video about it being 8 years old or so without any sign of activity (200 views, no updated description, nothing), and got a reply very quickly, asking along the lines of "What aside DAG is lacking in this video?" I answered in a long answer what is wrong about having 8 year old videos that look completely outdated, and are in parts (DAG), without mentioning them, but didn't get any reply back. Information that is not verified is useless. Verification of information deteriorates over time, it needs to be refreshed. If I give you a 15 year old manual of git, and half of it is wrong, but the other half is still right, asking you "What is lacking in that manual besides the wrong info?" is... I don't know what to say. Wrong information is like a mouldy apple. Just one in a basket is enough to spoil them all. I don't know, this all doesn't feel like it should happen with plastic, given how it markets itself as the snappy and smart solution to version control, not like those slagged old giants who are everything but agile. Thanks again for making it this far if you made it. I appreciate you taking the time and answering me, my argument here is made against a made up entity "plastic makers", that is nothing like all the people who in reality work on this, and has me projecting attributes to it that are born from my negative experiences, so please don't feel judged personally. I just suffered a lot because of this, and I have a big interest in people not having to suffer the same as I had to, and people having a good time with plastic - which is in your best interest after all. Have a good new years eve, and a great next year for you and the team!

I get there needs to be a system that covers all eventualities, but this is not normal: - A group of artists has complete access to everything based on repo permissions - The artists are on different branches they are not supposed to be on - I tell artists to move to the branch they are supposed on, submit their changes where they are and that I will merge them into the art branch afterwards. - Everyone confirms to me they switched to the art branch before - I do the merge, revoke permissions to view and read for all other branches they are not supposed to be on, going to bed knowing that now everything is fixed, they are on the correct branch and have the correct permissions - I wake up, a lot is broken, some artists are on different branches than art, they have no permissions to even view the branches tab at all, despite having permissions to view at least some of the branches, just not the ones they were on any more. My thinking is, that probably the artists made human errors, and switched to the wrong branches, branches where they then afterwards got the rights revoked from. Now, since they don't have view rights for the branches they sit on, they can't even open the branches tab to switch branches. Which seems like a design flaw? Just give the user the option to view the branches tab excluding the currently active branch if he doesn't have permissions to view them. This is just creating overhead for admins. On top I didn't find any information in the plastic administration guide on how to test permissions for users either, so I assume that's not possible. I think given what a central feature permission management is, how unintuitive it is designed, and how many gotchas there are around the software (like being easily able to revoke your own rights without warning), this lacks really in proper warning and headsups. It might be somewhere in the security guide but I as a user have reason to assume that if there is nothing mentioned in depth on rights management in the administration guide, even if its a link to the security guide, that there is just not a feature like that. Feels like the two biggest issues everyone has with Plastic are permissions, and not realizing that plastic doesn't work on per file tracking, and none of these are really clarified at any point without digging through hundreds of pages of documentation. I've seen so many forum posts about these two topics already while researching my issues, that I'm just shaking my head how you admins here didn't already get sick of repeating the same things over and over again, and haven't already forced the marketing people to at least let a tiny bit of informational content onto your main landing page. For instance a row in the table called "How Plastic is different", with the title "Per File Tracking", and give perforce the checkbox and a cross for plastic? But no, can't have crosses there on the landing page I suppose. Marketing can not allow informing the user about potential benefits AND drawbacks of design choices. I mean, you are not perforce, and you have probably good reasons not do be - but advertising that you are perforce, just better (more checkmarks), and then turning out to have a fundamentally different architecture? Yikes. Also I've seen answers here before like "This permission system makes sense if you have thousands of users to manage" - yes, but 90% of all unity users don't need to manage thousands of people in teams. I think I understood the permissions now (all branches inherit from repo perms, can be overwritten on a per branch basis using the overwrite). I still didn't get why it needs an extra overwrite button. Why not just be able to directly change it by ticking the other box? But alright, there is probably a reason for it, I'll just roll with it. But the thing that you just get locked out from viewing any branches at all, just because you have no view rights for the branch you are on, is really not excusable with a good reason for this to work like that, or I'm really eager to hear it. Don't get me wrong, I have big admiration for projects like this, and I respect anyone working on creating software that lets us be productive. But at a certain point there is also a level of respect towards the user - who is also spending his precious life time with your software, and getting lured into a software with marketing claims just to see its all not as advertised is just leaving a really sour taste of disregard of the user, at least from the marketing department. And that without even a real reason. Just tell the user what he can and what he can not expect. Don't put a list that says "everything and more" and then don't deliver. I pushed for using plastic in my company, we are multiple teams with around 100 developers and artists, and so far I am starting to regret that. It was not just me luckily, so its not my sole responsibility for all the trouble that switching to plastic has caused us, but this should be a warning signal to you that something in product -to-customer communication is really off. And by that I mean that: "But look, here it's written on page 495 of the manual, we don't have that feature, our architecture is fundamentally different from perforce.", after that being omitted by advertisement, is far from good communication. I wasn't here 5 years ago when you did that, I have no knowledge of the history of plastic at all. I see checkmarks that tell me plastic can do everything that perforce can do, I expect that to be the case. It's not. Your program is good, just give the user a warning before he locks out users from operating the software at all by changing permissions, either himself or others, and make a section close to the differences table that explains why you went for DAG and ditched the per file tracking. So much worry and stress inflicted for literally no reason at all but failing to communicate. Do better, it's not just your time you're wasting here, but mine as well. Maybe I'm just a frustrated idiot, but I don't think so.