Thanks for the suggestion.

But don't you mean something like the "webtrigger" we already support?

https://www.plasticscm.com/documentation/triggers/plastic-scm-version-control-triggers-guide.shtml

The good thing with Plastic is that you can install the client entirely just with xcopy deployment. No need for anything in the registry.
This is only broken when selecting Visual Studio components (which, themselves, require to mess with the registry and more permissions).

Many corps using Plastic deploy with some xcopy-like technique, just copy binaries and done.

Makes sense?

One thing you can do is as follows:
* Put this file inside a folder, alone, in the original project.
* Xlink to that folder from the other repo.

Makes sense as a temporary workaround?

Uhm... we closed this for a reason: not enough traction/interest.

What you ask would be *doable* if the shared file is readonly when xlinked, I mean, you can't modify it.

But I bet you want to make it writable, right? Full VSS semantics.

If that's the case: it is simply not doable today for us, because concurrent modifications could end up with merges, and merges require merge tracking, and merge tracking in Plastic is per-changeset, not per-file (like it used to be prior to 4.0), and then... well, simply we can't handle an individual file like that, we need to handle the full tree. The explanation is not straightforward unless you are familiar with how modern DAG-based version controls work.

Interesting. We are more about to get rid of tabs in future releases. We don't have them anymore in Linux and OS X... and seemed to be a good idea.
Pinned tabs look like a good idea too... will share with the team.

You are asking for something like git squash, some sort of history rewriting, right?

Uhm... it is powerful but dangerous. I mean, if you push that branch to other server, you'd be in trouble.

That being said, it sounds interesting. But we should probably have to rewrite all descendant changesets too, uhm... yes, something like squash is what you want here :-)

Why doing a subtractive merge wouldn't work for you?

Branch Explorer already autorefreshes each time you checkin (even when you undo, which is not correct).

To be honest, I profoundly hate GUIs which auto-refresh, they all end up eating up CPU when they should not. And that vision is certainly affecting the product :-)

Can you better explain why auto-refreshing is so important for you? I mean, what do you really expect? Check changes made by others on a centralized setup?

Got it.

What would you expect here? Resize to same size?

Why do you need a new workspace?? Why don't you just update your existing one??
Sounds weird.
Workspaces have nothing to do with AUTH.

Love the suggestion. Color or format changeset based on attributes, correct?

You are right. No reason not to. We'll do.

Got it! Shouldn't be hard at all

Ok, I guess you mean a Plastic SCM Cloud Edition for Linux, pre-configured, with the client setup and so on. Well, can be done.

Anyway, installing on supported distros is a snap right now :-)

Yes, this is a good one that is related to having triggers on Cloud and also a full pack of improvements we need for the code review.

Took good note of it for the review/refactor/rework of our code review system.

Thanks!

Hi,

Actually what the interval does is (9, 15] as explained here: https://www.plasticscm.com/documentation/advanced-version-control-guide.html#interval-merge

There might be better ways to explain it, definitely, but we didn't find a better one :-S

It all goes to the diff concept: when you diff 11, you are actually diffing eleven vs 10, right?

Have you seen our built-in semantic differences?? We use the outline of source code to collapse differences. Does it help? Or do you have in mind something that is not C++, C, Java, C# or VB.net??

Thanks Ignacio!

But the link seems to be broken :-S

But why do you want to replace it in the merge tool if this is how your code is actually written?

Does your IDE does this?

Thanks Christian,

Would you mind elaborating a little bit more?

Yes, this is very interesting and not hard to do. We have to work on a batch of GitServer changes, and we'll consider this one then.