psantosl
-
Posts
989 -
Joined
-
Last visited
-
Days Won
26
Posts posted by psantosl
-
-
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
QuoteOh man, how I wish it could look as good as that Visio chart! The font choices there are SO much better than any of the images or the current UI. It's so much more legible!
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.
QuoteLike jwvanderbeck, I'm on a 4k monitor, and so many of the fonts are illegibly small faint scratchings. I'd be so happy to see fonts like that Visio chart, I'd actually be able to read everything at a glance! If nothing else comes over, please replicate those text changes exactly!
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?
QuoteThe first thing I wonder about the fixed tabs is what happens when the tab bar is full enough that it needs to scroll? Are the pending changes stuck on the left, and my most recently opened History panel is on the far right, and I have scroll the entire bar left to right and back to use them both? If the tabs can be moved, I can put the main tabs in the context where I'm using them. I don't know if it's that big of a deal, but being able to unpin the main tabs an repin them when I want seems like a safer bet.
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.
QuoteI like the idea of switching to a New Tab picker for actions, but the layout seems a lot less readable. My eye has to bounce around between a bunch of abstract icons and small text scattered around the page. The old UI is a single list of text that I can skim down pretty quickly to find the name of things I'm looking for. If the next tab page had an equally skimmable layout, I'd be for it. As it stands, I'll switch back to the old way (even though I agree the new tab page method is better). The "Plastic SCM" category of the home screen is a much better example of a layout I'd like to see on the new tab page.
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.
QuoteIf the goal of the Home panel is to reduce clutter/gore for new users, it feels like having a "News" section runs counter to this. That's some advanced user reading material right there, and it's super duper noisy. The "New" tags draw your eye away from the core use of the software, and the text density says that this should be the body of your work, not an exit to a web page.
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!
QuoteA general comment: With wide screen monitors, horizontal space is easier to give up than vertical space. Vertical space is a premium. Please keep that in mind when adding things to the vertical space. Using more space for the headings and tabs allows you to put more info there, but takes away from the precious limited vertical space for the main part of the screen. At least having an option to put this on the left hand side vs top could be nice.
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 🙂
QuoteI understand wanting to make the gui more accessible for new users. But you need to also not leave users that are used to the system. Ability to control the interface, to a degree, can be useful in this (e.g. minimal view, vs more info view). I can already see some operation I do taking more click in the new interface than in the old. One thing I do (admittedly more in tool admin role than as a developer) is open up the list of repo, then view a repo (e.g. branch explore a repo w/o a WS). It looks like now I have to first click to create a new tab, then select repo list. I assume the rest of my operation would be the same from there, but still at least one more click.
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.
QuoteIt would be good to have the GUIs more similar across the platforms (for us, esp Windows and Linux). But my first priority would be making features available in one gui available in all. While I could see this consolidating effort a step in that direction, I hope we do not take a step back and see features go missing (e.g that are already in the windows gui today). I would REALLY like to see some missing functions added to the gui as more important than a gui re-design. How long have we now had the ability to create xlinks to a path in a repo, but still have to create it only using the CLI? That (and any other missing functions) need to be added to the gui.
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.
QuoteI could see more customization of the gui, esp for experienced users. Say, being able to have a custom left hand "new tab" buttons on the left hand side (hidden and empty when you first install the client?) I could also see more customization to right click menu options for experienced users (not only for tabs for for other contexts).
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
QuoteAt first glance I wasn't sure about removing the left hand menu, but then I realised how everything opens up as a tab anyway, your suggestion makes sense. It's useful to have as much usable space on screen as possible, so reducing unnecessary clutter is helpful.
I like the idea of distinguishing between different kinds of tabs through colours or icons. It's confusing when you end up with a mix of static/pinned tabs like Branch Explorer, Workspace Explorer, buried between more ephemeral tabs like merge results, 2d history views, where it's easy to forgot why they were opened in the first place.
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:
QuoteAlso not being able to use shelving for cloud users would be nice
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,
QuoteI have found it strange that all tab-views have to exist within the context of a workspace. Whenever I work with Plastic I often end up with a tab list like this:
QuoteThe first thing that feels unnatural to me is that "Cloud repositories" opens as a tab within a Workspace view. The second thing that feels unnatural to me is that if I begin to drill down into another repository, the additional tabs continue to open up within a Workspace view.
QuoteThe "Open repository" option would ask me to choose a repository, either on my local server or on the cloud side. After choosing a repository, I would then have access to a subset of tabs within that view (only the tabs that make sense when browsing without an associated workspace). I would set up a couple of these workspace-less views, for projects that I don't actively work on but follow discussions on, and keep those views for a long time.
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.
-
Quote
These changes but good! But I do have to say as an end user the GUI is not the painful part of Plastic, but rather unexplained/strange conditions.
Any effort to address error states/messages better would be an even bigger win, in my opinion. Just these 2 we brought up here for example:
- Renaming a branch causes other workspaces referencing it to "break" without explanation (just error messages)
- "Hidden changes" causing a warning that looks unrelated, every single time you switch workspaces (even if having changed files locally is the intended usage pattern for hidden changes!)
Also not being able to use shelving for cloud users would be nice.
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!
-
Quote
My first impression is good. I use manually "pinned" tabs too. Mine are Workspace Explorer, Pending Changes, Branch Explorer (and sometimes Sync repositories), in this order; but I can get used to the order from the blog post, so this should be OK for me.
@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
-
1
-
-
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?
-
-
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.
Cloud/Local Diff or Force Update?
in General
Posted
Ok, let's see if I can help: