Hi Lauri,

We need to understand this better.

Why do you need to download a folder to disk instead of switching to the branch and working on it???

pablo

Hi Göran!

Yes, I understand your request, but we need more interest to go ahead.

These sort of features, while interesting, seem to be not very appreciated by many, and end up cluttering the UI, which is unfortunate.

Thanks!

pablo

Hi Nick,

No reason why not...

I'm adding this to my list of usability requests. Please PING ME if we don't answer in a reasonable time... we need you guys to push :-)

pablo

Hey Ondrej,

So, opening our own editor to show files instead launching an external one, for speed purposes, right?

pablo

Hi Eamon,

Super interesting indeed! This is one of the features we'd love to implement :)

pablo

The annotate tells where the change was made (on which changeset and branch). You can check when this branch is integrated in main using the branch explorer.

It also can be done by CLI using the cm find merge. Example:

We know by the annotate that the line was changed on br:/main/task. In order to know where/when the br:/main/task was integrated on main we use: "cm find merge where srcbranch='br:/main/task'"

I don't know if this could be enough.

Thanks for sharing this. We are finally redesigning code review. So we'll be considering all suggestions.

Thanks for the feedback!

Looks like a good idea indeed.

Hi Vincent,

Doesn't "find in files" during diff help with this? Maybe you didn't know the feature exists, I don't know :-)

Any suggestions on the hotkey?

Hi Brandon,

Thanks for sharing this.

We are working on a bunch of features to support DevOps, and better triggers (and support for Cloud) will be part of it.

What we have in mind is something like what Slack does for bots: you open a websocket to the server (the cloud server in your case) and then register which repos you are interested on, and notifications will come.

We prefer this better than regular webhooks so that people can configure their hooks behind the firewall, no need for public endpoints.

pablo

Thanks Mikael,

You're right, we should handle this better. The dialog is copyable (just CTRL-C) but this is no excuse.

We just implemented a quick solution, didn't spend time on a custom dialog, just used an standard one.

About automatically distributing it: yes, would be nice, but since it is free, we prefer the user to download it.

pablo

Hi Damian,

Do you know you can have more than one repo in the same sync view?? This is how most people use it, so you can calculate all syncs in one shot and you won't need the icon you are looking for.

Hi Bobby,
We don't understand this.
In pending changes you have a diff viewer embedded that you can use to diff each selected file. What is the advantage of the CTRL-D?

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?