mklasson

I see. It was not clear to me that that was clear to you. Again, I'm sorry for the frustrated tone in my previous comment. Okay, I'll do so. Thank you, that's very helpful.

I feel like I'm failing to communicate with you. Did you read past the line about "hidden_changes.conf" in my previous message? How could your suggestion about the setting possibly help with what I've been describing? As best I can tell, the client behaviour I'm describing would not be valid for _any_ of those option settings. If my setting was "Allow" then the workspace should update successfully. It does _not_, despite plastic saying so. If my setting was "Allow, showing a warning" then the workspace should update successfully and plastic show me a warning. It does neither of those. If my setting was "Do not allow, show an error" then plastic should show me an error. It does not. Again, plastic _says_ the update was successful, but in reality it wasn't. The workspace was _not_ updated. For the record, my setting is "Allow, showing a warning", which is what the legacy client does. The non-legacy client instead shows the buggy behaviour I've been describing repeatedly here. Am I having a severe brainfart and completely misunderstanding something? Could you _please_ take a moment to read my entire message and tell me if you agree or disagree with my conclusion that the behaviour I'm describing is a bug? If there's something you don't understand about what I'm saying then please ask me about it. I feel like I'm wasting precious time currently. You really don't need to review my logs in detail to be able to tell me whether what I'm describing is actually a problem as I'm claiming or whether I'm just stupid and misunderstanding something crucial. The latter seems unlikely at this point, but if that's the case, again, _please_ tell me so I can stop wasting all our times. If it's the former then we can move on to whether it's some weird glitch in my particular system or whether it's actually a bug in your plastic client that you can then fix. I'm assuming that should be "support@codicesoftware.com". Sure, I'll send an email there as well. If you could also please answer my question about whether the legacy client has really been removed from the newest plastic release I'd very much appreciate that. If you don't actually know then just say so. Currently my questions and comments seem to just be ignored or skimmed over which is very frustrating. And this is on top of waiting 8 months for any response whatsoever and making two follow-up bumps since I first tried to bring the problem to your attention on your own bug-reporting forum. I apologise that my frustration about all this is no doubt coming across to some degree. The clear lesson seems to be to not waste time reporting bugs, which presumably is not the lesson you want to reinforce. Here's the core problem of everything I've said again: Plastic _says_ the update was successful, but in reality it wasn't. The workspace was _not_ updated.

Hi Rafael, It's good to finally hear from someone. No, I don't have a hidden_changes.conf file. The problem seems much simpler than that. I can see in the pending changes list that I have changes. In that situation, when I click "Update workspace" in the old legacy client I get an extremely helpful message stating that fact and offering solutions: By contrast, if I do the same in the new plasticX client (currently v11.0.16.7419 as I don't want to update and lose the ability to use the legacy client) then all I get is the status bar saying: That message obviously makes me think the workspace was ... successfully updated. It was not. Plastic _failed_ to update the workspace and then made matters much worse by telling me everything went great. Now, the ideal solution is to make the new client behave exactly like the old one does, informing me of reality and offering help. The bare minimum solution is to make the new client say "Workspace update FAILED because there are pending changes." A program telling you something was successful when it actually failed is obviously a cardinal sin. Also, can you please confirm that you have indeed removed the legacy client from the newest version? Like I said, I'm reluctant to update if that's the case as the legacy client is still a useful well-functioning backup. Maybe fixing this bug will push me over the edge though. Thank you, Mikael

I posted https://forum.plasticscm.com/topic/23287-workspace-update-blocked-due-to-pending-changes-dialog-not-shown/#comment-45756 7 months ago and then a follow-up 2 weeks ago. I still haven't heard anything from you. The status bar says "Workspace successfully updated" after pressing it, but that's a complete lie. It fails to update and does nothing. Are you aware of the problem and intend to do something about it?

Is anything going to be done about this? I just wasted some time again today when the new gui in plastic v11.0.16.7419 silently ignored me pressing "Update workspace". Switching back to the legacy gui it helpfully showed me this: Having the new gui pretend nothing is wrong, leaving you scratching your head wondering why the files don't seem to update, is a real problem. From what I understand you're now also removing the option for using the legacy gui? Meaning I'm gonna waste even more time next time this happens. Please fix this.

Sure: DEBUG ExceptionHandler - Stack trace: at System.Collections.Generic.Dictionary`2.FindValue(TKey key) at TextMateSharp.Themes.Theme.Match(IList`1 scopeNames) in /_/src/TextMateSharp/Themes/Theme.cs:line 42 at AvaloniaEdit.TextMate.TextMateColoringTransformer.ProcessTokens(Int32 lineNumber, List`1 tokens) at AvaloniaEdit.TextMate.TextMateColoringTransformer.TransformLine(DocumentLine line, ITextRunConstructionContext context)

This suddenly popped up when I alt-tabbed back to plastic. I'd changed a source file that I think was visible in the diff view. I could continue working after forcibly killing plastic. What exactly has been corrupted and should I be concerned?

Using the new GUI this dialog: is _not_ shown when pressing "Update workspace". Instead the update just silently fails. I had to switch back to Legacy to find out why my updated files weren't showing up.

For anyone else struggling, I finally got this working. First step for me was to use --format="rev:revid:{id} {item}" with cm find and then piping through another filter to match on but strip the item part. For whatever reason though cm archive doesn't seem to understand what repo the id refers to, despite running from inside a workspace. It just said "rev:revid:17 does not exist" and quit. Adding the repo spec as well fixed that, e.g. adding "@rep:Dicey@local" after the id. Let me add my voice to the chorus of people asking for an easier way of doing this. And if I'm misunderstanding something or being needlessly complicated I'd appreciate hearing about it.

This doesn't seem to work at all as the output from "cm find" is not recognized by "cm archive", which aborts with error "Incorrect object specification <...>". If I use '--format="{item}#cs:{changeset}"' with find then things work better, at least until it comes across a file that was later moved. Then archive says "<...> does not exist." and grinds to a halt. Could you please tell me the proper working syntax for how to achieve this? I imagine using {id} in some fashion might work? This is on windows btw, if that matters. I've noticed another weird thing with your windows client: cm find outputs paths with backslash as separator if you run it from inside a workspace, but outside a workspace (using the 'on repository' parameter) it instead outputs paths with slash as separator. This seems like terribly inconsistent behaviour and caused a lot of headaches yesterday until I realised what was going on.

Thank you, and also, apparently in the latest Plastic version I actually do get a popup offering to merge the changes or create a new branch now when trying to check in. So all good, sorry to bother you.

Repos A and B both have wxlinks to repo C. Initially both wxlinks point to cs 388 in C. I then check in a change in C from A. Next I try to check in a change in C from B, without updating the wxlink to point to cs 389. This complains about incoming changes and takes me to that view, which is empty. How am I supposed to proceed here? I'd like to get a chance to merge the changes, but I'm not given that option. I tried shelving the changes from B, which allowed me to update B's wxlink to cs 389. But weirdly that shelf then wants to, in addition to changing the source file I changed, also change B's wxlink to point to cs -4. What's up with that? It wants to update the wxlink from "wxlink:FluffLib:/@388@FluffLib@local" to "wxlink:FluffLib:/@-4@FluffLib@local".

That's perfect, thank you so much! Best, Mikael

Hi, Is there any way to configure how big a file needs to be for Plastic to deem it too big for automatic diff when viewing pending changes? Or maybe a way to tell plastic to always automatically diff a particular file or even all files? Having to always manually click the "Calculate differences" button for a particular file (Unity scene file in this case) wastes time and interrupts flow. At the very least the current threshold seems flawed. When actually doing the diff takes about a third of a second and clicking the button takes two seconds then that's a bad experience. Thanks, Mikael

I ran into this problem after updating the plastic client through its built-in update feature that downloads the client installer only. For some reason that installer seems to have also decided to uninstall the server component without asking. After manually downloading and running the full installer (incl. server component) the server is back up again with no config lost and the license problem is also solved. I strongly suggest that you change the client installer to not remove the server component without asking. Ideally the update feature inside the client should download the appropriate installer, client or full, depending on what's already installed on the system. Thank you.