psantosl

Ok, let's see if I can help: First thing is to take into account you can work distributed or centralized. Not sure if I'm saying something too obvious but: Distributed: you have a local repo => git like Centralized: you directly checkin to cloud (or any other central server, can be an on-prem one, for instance) All the info (maybe too academic) here: https://www.plasticscm.com/book/#_centralized_distributed Once you solve the merge conflict (you need to push first if there are conflicts upstairs, like Git), checkin locally, then push, and the conflict will be gone in the next pushes.

Ok, I'd have to take a look into those automatic conflicts, since I understand they are at directory level. If so, normally automatic ones means there's really no possible human intervention, they are just discarded based on the merge logic. But I'd have to look into it. Regarding the source/destination: here is the best explanation we have: Then a full chapter about it https://www.plasticscm.com/book/#_merge_contributors_source_destination_and_base

You mean some of the conflicts were automatically solved and others not, and some of the automatic are not ok?

Hey! It really depends how your workspace is setup. Your workspace can be pointing to a local repo (if you installed Cloud Edition, you could be using a local server and local repos) or directly to a cloud one. So, if you're on a local repo, it is a Git-like situation: you should pull from Cloud before updating (and yes, we do it in two steps, not one like Git). See what I mean? Check where your workspace is "pointing to" and whether it says "local" or "cloud". Pending Changes always shows diffs comparing what you changed starting from a given changeset, but it won't show differences with the head, just with your starting changeset (incoming changes on the other hand, will show you diffs with head). Hope it helps, but let me know if it doesn't. pablo

You don't need the SDK. Just download our .NET Core build from our site. In case of Linux, we even have a proper package. Check the instructions. Once you get it installed, I think copying the DLLs will be enough. You don't need to do dotnet new and all this stuff

You can try the same with our .net core server build (check the download page). It uses the most modern .NET Core, and probably version issues are gone. (you'll need .net core compatible libraries though) I'm very interested on this, we could write a blogpost and share with others

Definitely no need for reference at build time. If the dlls are there, it should work. Only issue (you can check) is if the assemblies of log4net don't match the log4net we use, or if they use a newer framework

Initially it means a file requires to be merged, so it looks like you started the merge process but didn't finish it. I'm trying to get help from Rubén who is the expert on this. Cheers.

Hey, You can use Personal, but then you have to host your own repos (no cloud) and it is for a single user. It all depends on your needs pablo

Hi Steve first quick answer: xlinks have nothing to do with workspaces. Do you mean repositories ?

Hi @Eric Carter Ahahaha, you made my day with this. Read this @danipen???? 😄 Dani tends to dislike my Visios because they totally ignore the GUI styles on each platform. I'll share this with him. Uhm... but Plastic (gluon has issues, although we'll fix it) should be working fine on 4K. Would you mind creating a separate thread with this? Initially we'll probably stick to the current solution, that doesn't scroll. Look at this screenshot (I made the window tiny to show the corner case): Tabs are simply made smaller and smaller. We'll consider the pin/unpin. I thought keeping the key 3 ones on the left, always visible, was good, but you are not the first one pointing caveats. Oh god! @danipen will think Eric Carter is actually me in disguise 😄 I tend to hate icons. I prefer text. My brain is fed up of remembering even another icon. Is like every app thinks they are smart to make you remember even a new icon for something. What they mean? Why are they worth? This was my initial lame proposal: Of course it is not as cool as "new tab" in Chrome, or the actual design I submitted above. This definitely requires giving it more thought. Not sure if everyone else agrees or if it is just you and me, Eric. We love to keep people up-to-date with the stuff we write, that's why, but I see your point! Thanks!

Hey @Todd A Needless to say I strongly appreciate you taking the time to answer us in our public forum. We communicate very often in private channels, as you know, but it is really great that someone like you, with such a vast experience in Plastic in a huge deployment, can find the time to openly share thoughts. Thanks! Absolutely true. I've been always concerned about vertical space. My motto here is "all monitors are wider than higher, let's use the space widely". This thinking drove most of our designs since I took full responsibility of GUIs around 2012. That being said, sometimes you need to use it a little bit, and I think the new "workspace info bar" on the top will be very useful. But yes, I'll keep in mind vertical pixels can't be wasted and will remind that to the entire team. I can now say Todd said that 🙂 Yes, you're right here, and that's a concern. We need a balance: let new users find their way, not annoy experts. And of course, all considering we don't have unlimited resources to do the perfect customizable GUI (and of course some designers will argue whether fully customizable GUIs are even best or not). One thing we'd like to radically improve are short-cuts. We never put too much attention on them, which is a shame. Maybe they'd help here. Anyway, sure, we need a way to highlight things like "accessing the repo list". I don't have a full solution yet, but I'll keep your concerns and remarks in mind. Sure, the goal is to change the layout, but not the functionalities. I mean, we don't plan to "delete stuff from windows" with this initiative. And yes, making the GUIs more consistent is one of the key reasons of this entire initiative too. Definitely a good point. I'm concerned on whether we'll be able to come up with something good if we go down the customizable GUI path, and not create some sort of Word-menu-configurator which is great but only 1% probably use.

Hi @Ramz-UK Removing the left side might be a wild move. We plan (let's see if we can make it) to keep some sort of "compatibility mode" to preserve the old looks. The thing is that for many new users, the current layout is overwhelming. Too much stuff. That's why we think cleaning it up might make sense. Thanks for your support!

@Francois Bertrand I forgot to answer you about this one: It strikes me hard because I'm the ultimate culprit for not having this one. There is a (very programmer-wise) reason: we plan to make a big change in the current Plastic Cloud. So I tried to avoid "strong changes" in the current one. What I mean? Right now Plastic Cloud is 95% the same code as a regular Plastic Server. The different 5% is: It is based on SQL-Azure for metadata (which is mostly the same code as for regular SQL-based storages, but with some retries and handling of 'increased latency' cases). But tree-storage (info about the versioned directories) is stored in Azure Blobs because using the SQL-backend doesn't scale. This is different than regular SQL-based for on-premise servers where performance for this part is fine. Data is stored in Azure Blobs and accessed directly (with security) from the client side, good for scaling. Since we started Plastic Cloud, we developed the Jet repo storage for on-premises servers. We migrated almost everyone from the SQL-based storages to Jet on all the on-premises servers. Jet is way much faster than anything else (it is an ad-hoc storage for Plastic, written with perf in mind, and after 14 years of development). In fact, Cloud was key for Jet, because what we learnt from the "tree-storage" in Cloud was what we applied repo-wide. So, the plan is to replace the current Cloud instances by Jet powered servers. The first advantage (development wise) is that now Cloud will be 99% the same code as on-premises, so things like Shelving would be enabled by default, no need to "develop it for Cloud" as it is today (due to some restrictions). That's the long story 🙂

Hi @Mikael Kalms, You nailed it! You sound exactly like Violeta, one of our Senior Engineers. She's constantly reminding us that we should not show "workspace unrelated views" this way. This made her happy. There's one caveat here: We were aware of the limitations/lack of clarity of the Windows layout. So we tried to come up with something different for macOS/Linux, where the workspaces/repositories views are not "inside" the workspace. But, we failed to implement things like: list repos, right click, show branch explorer/branches/csets/whatever for that repo. Indeed an "open this repo" that creates a new window with all the workspace-independent options available sounds good. And an extra option to "create workspace for this repo" so the window can optionally become a fully functional one. Believe it or not, this is the "next phase" once we implement the proposed changes above.

Thanks @Francois Bertrand. Yes, of course, you are entirely right. We'd like to come up with a better GUI, you know, it's been a while since the last redesign. But it doesn't mean it is our highest prio. If you check the release notes of our weekly releases (we stuck to twice a week for months, although we slowed down since end of the year holidays) you'll see our key focus is stability. I'm taking note of these two ones. Thanks!

@JakubH thanks for your feedback, as usual. You know you are one of our key users, and we always love to hear from you. We'll try to come up with "smart defaults", but let's see if it is any good :-). Sync repos is a key one too, correct.

First of all, sorry all for not coming back to you earlier. We read all your comments in great detail, and were very excited about the feedback. I wanted to write proper answers, and unfortunately that meant I took too long to come back. I'll start replying now.

Carlos, I think this is going to be fixed in BL3799

Well, you mean revisions not loaded by csets newer than a certain date, since a new cset can be loading a very old file rev that was never changed how would you like to define that? Gui? Conf file?

This exact feature is something we have in mind 🙂 What would be the ideal to specify this?

Hi @Meceka and @Marc Audouy As Carlos said, right now we don't have a way to trim databases, but this is something we'll be working on soon because it does make a lot of sense. There's a workaround you can use, but it is not trivial: it involves cloning the full repo locally, trimming the data, pushing the new repo, and then deleting the old one. Let me share the idea with the team and I'll get back to you. pablo

Hey, a few releases ago we added this preference: https://www.plasticscm.com/download/releasenotes/8.0.16.3552 But it should be a preference and shouldn't be set by default. Can you confirm this is the case?

This will do:

Would you guys @gweronimo @SWSBB @jwvanderbeck like to have an online meeting next week and we talk about your proposals in person? We'd do a GotoMeeting or something.