Official [Announcement] Plastic SCM joins Unity!

Plastic SCM joins Unity! Here is the Collaborate to Plastic SCM Migration Guide.

Hello fellow creators!

As you may have read on the blog, we are thrilled to welcome Codice Software, the company behind Plastic SCM, to the Unity family!

We built Collaborate to give users the ability to share projects amongst small teams who want an easy way to sync their projects without navigating the complexity of version control. We brought Plastic SCM into the fold for larger teams looking for more advanced features like branching, locking, merging and a standalone GUI.

We believe that it’s important for creators to have the flexibility to pick the tools that fit their development and team needs. That is why we are committed to making sure that Plastic SCM, Collaborate and other third party version control services continue to receive support.

If you wish to migrate your Collaborate projects to Plastic SCM, you can check out the step-by-step migration guide below to get started. This guide will walk you through the process of migrating Collaborate projects with the Collaborate migration tool, inviting your team members, setting up your Plastic SCM workspace and getting the new Plastic SCM for Unity plugin (now in beta).

Collaborate to Plastic SCM Migration Guide

Videos

• Migration Wizard
• Plastic SCM Plugin Dev Mode
• Plastic SCM Plugin Gluon Mode

Migration Steps

Step 1. Access the Collaborate migration tool available on the Plastic SCM website.
Step 2. Click on Get Started and follow the wizard to migrate your Collaborate project(s) to Plastic SCM.
Step 3. Download and install the Plastic SCM Cloud Client.
Step 4. Open the Plastic SCM Cloud Client and log in.
Step 5. Select the Organization that you have created with the migration tool.
Step 6. Select the workflow that fits your needs.

• Gluon Mode, a workflow tailored for artists. This workflow lets you pick the files you want to work on and check them back in without having to update your whole workspace. If you need to work inside the Unity Editor, make sure that you configure Gluon so that it pulls down all Unity project files required to open a Unity project.
• Developer Mode. If you want to check in your changes directly to your cloud repository, create your workspace using the centralized tab.

Step 7. Create a workspace.

• If your Unity project files are already on your machine, select the path on disk that corresponds to the root of your Unity project.
• If your Unity project files are not on your machine, you can select any location in which you want to create your workspace.

Step 8. Update or Configure your Workspace.

• If you choose to use Gluon Mode, make sure you configure the workspace so that it pulls down all Unity project files required to open a Unity project.
• If you choose Developer Mode, update your workspace in order to ensure your project is up to date with all incoming changes.

Step 9. Open your Unity project through the Hub.
Step 10. Go to the asset store and import the Plastic SCM Plugin for Unity (beta) plugin.
Step 11. Disable Collaborate from your migrated project by clicking the Off button on the Unity Services window or in your Project Settings.
Step 12. Check in your modified Project Settings.

You are now ready to work on your project using Plastic SCM!

FAQ
What does this mean for the development plan you had before?
We are committed to ensuring we provide you with a choice between a workflow that allows smaller teams to sync projects without navigating the complexity of version control and one that can benefit larger teams looking for more advanced features like branching, locking and a standalone GUI. This means we will continue to support Collab with its current feature set.

Where should I post questions related to Plastic SCM?
You can post questions in the Plastic SCM forums. For any questions related specifically to the migration tool, the Plastic SCM plugin and using Plastic SCM with Unity, you can reach out through the Plastic SCM Unity forum.

 

What does "continue to support Collaborate" mean though? Last time I heard, it was undergoing a full re-write, since it had too many problems that couldn't be fixed (like constant editor freezes), will that still happen?

If not, and as it is implied in the post, and those of us who have somewhat big projects and have problems with collaborate should move to PlasticSCM, what are we going to do about the incompatible limits of each platform? (Collaborate has a limit on project size, PlasticSCM has a bandwidth limit and we really don't know if we can move to PlasticSCM).

 

"Continue to support Collaborate" means we will not add new features but we will continue to support its existing feature set by fixing bugs and ensuring the latest editor version is supported.

We know some users are running into scalability issues with Collaborate and/or are in need of a more advanced features. To help with this, our first priority is ensuring that we are offering you a choice. This is why we have introduced the migration wizard - To help those who want to transition to do so in a few steps. We are committed to supporting both simplified and advanced workflows for version control in Unity now and in the future.

The pricing for Plastic SCM is based on the number of users and storage. It does not have a limit on bandwidth (except in cases of excessive use of egress).

• The first 3 users and 5GB of Cloud storage are free. For example, if you have 5 people on your team, you pay for 2 users out of 5.
• Storage is based on the size of your repositories. You can get more details on the pricing here.

 

So that's a NO on the re-write happening.

You might want to fix your websites then

That's from the FAQ https://unity.com/products/plastic-scm

The advanced feature we need is: 1. not pausing the editor for 2 minutes every 10 minutes. 2. Not corrupting files. But sure... "choice"

 

I'm not sure this is good news for us Plastic SCM users. This actually raise some concerns because of the terrible experience most of us had with Collaborate.

To be direct, I've moved away from Collaborate because it was (and still is) broken and the team behind it was (and still is) unprofessional. I've had the opposite experience with Plastic SCM and would like to keep it that way.

How do I know the people responsible for Collaborate will stay away from Plastic?

 

An other concern I have if that Collaborate is part of my Unity Plus subscription. I've subscribed to Plastic because your service isn't fit for professional use.

Since you now own these two services, you're selling me a solution to a defective product you're responsible for.

How do you address that conflict of interest?

 

How do we donwgrade our Cloud Editions to Free Cloud editions?

 

Plastic is great, I've used it in the past and it's in my opinion the best solution for version control when working with Unity. Congratulations on your acquisition, Unity!

Now, how will this affect users? Will Plastic continue being a paid solution? Will Unity Plus/Pro subscribers get a special deal or something in the future?

 

What counts against “Cloud Storage”. Is it just project size (like Collaborate?), or is it also History and network traffic (like it’s implied but not clear on PlasticSCM’s site).

You are asking people that used a very different pricing model (Collaborate) to a potentially completely different way of pricing and you’re not being clear on what that new method may be, and yet you’re urging us to migrate.

 

Seems History counts against the 5GB, and you can’t even delete really old versions of your assets.

https://forum.plasticscm.com/topic/21799-trimming-to-reduce-size-of-the-database/

Feels like a recipe to have Collaborate users (that were urged to commit often), start paying top dollar to have like 1000 versions of their lightmaps in cloud storage.

 

At the moment and as far as I know, Plastic bills you for the total history. So if you have a 1MB texture that you updated three times today, il will take 3MB of storage.

I never heard of a network trafic limitation. It's probably a typo from Unity.

 

Yeah. I also opened a thread about this last year so we wouldn't keep too much versions of data like lightmaps. https://forum.plasticscm.com/topic/20801-data-usage-optimisation/?tab=comments#comment-39254

At the time my request seemed to be a niche market but this may change.

 

I know you’ve been happy with PlasticSCM, but I’m not about to jump to another Unity owned versioning system, with obvious flaws (and also pretty expensive for our use case) in hopes that one day they will fix them.

 

I see where you're coming from but this isn't a flaw. It is, as far as I know, the standard way of billing storage for version control services. Yes it could be optimized but you're paying for what you're actually using, nothing unfair, misleading or unreasonable.

Collaborate doesn't make you pay for all your past big files iterations but they can "afford" to do that because they have more subscribers than they have users. Basically, they store what they don't bill you on the users who can't use their space because the service is broken.

I'm not sure why you consider Plastic expensive. Even with my 200GB storage, my last monthly bill was $42. Beside the price, I also consider the quality of service: bugs, services interruptions, complicated settings, lack of availability, false advertising and so on are many ways of costing you money even though this won't appear on your bill. Collaborate did cost me a few grands in late 2018 because it severely limited my productivity.

If you're also in that situation and you should do the math for a fair comparison.

I understand your lack of trust in Unity when it comes to version control, but the team behind Plastic isn't the team behind Collaborate. I honestly don't see any scenario where switching to Plastic wouldn't be beneficial. It was true last week end is even more now that Unity basically disowned their own service.

 

I don't know how well compressed history is, but for our use case, I see us getting past 200GB pretty fast.

But yeah, understood and all fair points, but I just want to say that setting up your own SVN on a shared hosting server (which is what we're currently considering), seems like a much better and more scalable deal than $42 for 200GB.

Especially since we don't really need any of the features PlasticSCM provides. (in fact we would have been perfectly happy with Collaborate IF IT FREAKING WORKED PROPERLY)

 

Yup, I had this problem with Plastic in the past. The musician accidentally rebuilt the entire music library (Wwise) and that made us upgrade to a (way) more expensive plan.

 

Moved from Collaborate -> GitHub -> PlasticSCM Cloud.
All in all, pretty seamless. VC in editor again is nice.

There are some oddities, some .asset files report changes even though a diff on them reveals nothing. I can only assume these might be timestamps on the files. Also having some conflicts with asset store packages containing the same assemblies as the plugin (Antlr3). Nothing a delete won't fix...

I will never, ever, ever miss the "checking for changes" dialog from collaborate... it ate a small portion of my soul every time I had to stare at it.

 

Thank you for the feedback. We are glad to hear the product has been useful for you! Please note that as part of this announcement, we have introduced a new tier for Plastic that is available for everyone. Plastic is now free for the first 3 users and up to 5GB of storage. You can get more details on the pricing here.

 

You don't need to downgrade. Free Cloud Edition is the same as Cloud Edition. As long as you use it with 3 users or less and 5GB of Cloud storage or less, the service will be free.

• Even as your team grows, the 3 first users will remain free. If you have a team of 5 users, you only pay for 2 users out of 5.
• Storage is based on the size of your repositories. You can get more details on the pricing here.

 

Thank you for your feedback and for making us aware of this. We have fixed this in the FAQ https://unity.com/products/plastic-scm

 

Hi everyone,

Please see the FAQ we just posted for more details on our plans.
FAQ – Plastic SCM joining Unity

How does Plastic SCM joining Unity change the development plan you had before for Collaborate?
The best path forward for Collaborate is to start from a strong foundation for version control targeted at content creators, rather than reinvent the wheel. Plastic SCM joining Unity is this foundation. Now that the Plastic SCM team is in the process of joining Unity, we are working hard on the logistics for Collaborate, in particular how it will leverage the Plastic SCM foundation. It is still a priority for us to make sure we provide a great version control experience with Unity that is simple to use.

How does this impact support for other version control services?
There is no impact. In fact, we’re so committed to making sure that Unity works great with all popular version control services that the Plastic SCM team will become the central team for all things version control at Unity. In other words, they will be entirely responsible for Plastic SCM, Collaborate, Perforce and all other VCS integrations in Unity. The team is dedicated to ensuring that all popular version control services work great with Unity.

You can see the more detailed FAQ here.

 

Yeah, so what's the timeline for that happening? When can we expect for Collaborate to move to the PlasticSCM foundation?

Also, if Collaborate moves to a PlasticSCM foundation, how will it differentiate itself from actual PlasticSCM?

 

How come the plug in is not supported on Windows? How are we supposed to migrate from Collaborate without the beta plug in?

 

@MassiveTchnologies, Windows support for the plugin is in the works and will be coming soon. We're sorry for the wait.

 

Hi @MassiveTchnologies,

The plugin is still in beta. We do officially support the LTS releases on Windows: 2018.4LTS and 2019.4LTS.

However, it is not yet supported for editor versions in the current tech stream (2020.1 and 2020.2) on Windows. We are actively working on adding support for these versions.

 

Thanks. Any approximate ETA for Windows support? (days/ weeks /months?)

 

The update will be released early next week. I will circle back here with an update as soon as the new version is out on the asset store. Thanks a lot for your patience.

 

@MassiveTchnologies Version 1.1 of the Plastic SCM Plugin for Unity (beta) is out now on the Asset Store. Support is now available for Windows on 2020.1 and 2020.2. Thanks again for your patience.

 

I just finished using the Collab -> Plastic migration wizard, and *then* found out that 'history' counts towards storage use. I'm now worried because I'm also using Wwise and I feel like it's going to quickly add up to a point where I can't afford this service.

@MartinIsla When you mention your musician rebuilding the music library are you talking about the soundbanks or something else?

I'm in a weird position because our audio guy and I need to both be able to work on the audio, meaning we also need to include the Wwise project itself in the repo. If our audio guy needs to tweak and reupload audio, and regenerate the soundbanks (hundreds of MB) several times each day he is working on the project, its going to make our storage usage very high. The old versions of these files are also completely unnecessary, so having them stored is a waste.

Is there currently any way we can mitigate this? I see Marc's thread in the Plastic SCM forums (https://forum.plasticscm.com/topic/20801-data-usage-optimisation/?tab=comments#comment-39254), which looks promising that the developers are looking into it, but nothing has been mentioned from the developers since last year?

If I'm missing some basic way of handling this I apologize (new to Plastic, still learning). But if there isn't any way to choose to not keep old versions, or manually go in and remove old versions, then I don't see how I can use this service which would be really disappointing because it seems great.

 

This is also a similar topic, my request of trimming to reduce the size of the database,
https://forum.plasticscm.com/topic/21799-trimming-to-reduce-size-of-the-database/

Right now I think there isn't any way, you have to keep those files out of Plastic version control.

We sometimes send some huge texture or scene files with google drive if it's going to have lots of changes in the short term, and we add those to Plastic when those changes are finalized. So, fewer copies in the database.

I know that's a terrible workaround and really hope they will add some functionality about this as soon as possible.

 

I'm sorry, I just saw this. When we were using git and didn't have to worry about storage, the musician always regenerated all the soundbanks because there were no downsides to it. When we moved to Plastic, we had to stop doing that because the repo size increased drastically really fast. I emailed Plastic support and they said there was nothing we could do about it, even if the old files weren't necessary.

In our case, we ended up using a separate git repo for the Wwise project itself and kept Plastic only for the Unity project. That worked fine!

 

Hey Martin, thanks for the response! How is it that you don't have to worry about storage with git? Does LFS do something differently then what Plastic is doing (like not keeping previous versions of the LFS files?)

 

I think we used GitLab which allows for free repos up to 10GB. I'm not sure whether that limit accounts for previous versions, but it never was a problem for us.

 

I'm working on a project stored on Gitlab and it does keep previous history like Plastic. I have to be careful about commiting lightmaps for that reason.

That said, I'm not the manager on this once so I can't check if there are any differences.

 

That's good to know! In that case, it was just not a problem for our needs because we only had the Wwise project there.

 

@Marc-Saubion What is your upload speed when you're using Plastic?

Mine is 1mbps, and every time I need to upload something over 10mb, it fails 90% of the time (with error "socket has shut down").

PlasticSCM support tells it's just that my connection is slow, which seems to imply that PlasticSCM is simply incompatible with slow upload speeds.

Which is... just great.

Have you ever had this issue?

 

Hi @AcidArrow.

I did have the same issue before I had optic fiber and there is a solution.

Currently what you have is your local workspace that sends your changes directly to your repo on the plastic server. It has a short timeout (probably in order to avoid conflicts) so big files tends to fail.

What you need is toi setup plastic with a local repo. This way, you work on your workspace(s) as usual, commit your changeset on the local repo stored on your computer, and then, you push/pull to synch it to the online repo on plastic servers. That additional step doesn't have the timeout issue so you can upload few GB overnight without troubles.

That said, I don't remember how to configure it (somebody from plastic did if for me) but if you contact them and copy paste my explanation they'll know what your taking about.

Let me know if it worked out.

 

This part I don't quite understand, since it doesn't fail at the same time every time. Depending on the size of the commit, it uploads everything (which can take up to several minutes) and then fails.

Also if two people upload at the same time, whoever finishes second fails, so it seems like that issue is handled?

Anyway, thanks for the reply.

 

Had to quit using plastic plugin. The plugin just doesn't work well. I can't count the number of times I "hid" assets like meshes with the read/write flag enabled from the change list only to have them literally show as changed every single time I open unity. It is infuriating. It also makes the editor super slow. Assets that create files also tend to break because Plastic is doing some weird things with them behind the scenes. I was asked for feedback months ago from the plastic team which I provided and have yet to hear anything.

 

Yeah, we quickly figured out the plugin was a no-go, we've been using the client, which has been okay apart from the whole "your internet connection is too slow for it to work properly".

 

I wouldn't expect much from the plugin because of its niche audience. Unity may have bought Plastic but it's still used by non Unity developer and experienced professionals are using the main interface.

Even though I initially advised Plastic to make the plugin, I think it's going to be like when unity had "Javascript": yes you could work with it but, because professionals where using C#, it meant you were stuck in a the hobbyists community. That's not top priority in terms of support and you're more likely to be using a tool that will be discontinued.

Looking back at my experience with version control, I realize the main obstacles where lack of documentation and general knowledge about basic principles. A lot of things about VCS in general is implied and never explained because people who are using it or making it already know about it. But it doesn't apply to self taught users so, for me, it felt like being new in a city that has no signs and no map because everybody else was born there and never needed direction.

I think they should work on a bunch of clear tutorial videos covering the basics instead. Cases like @AcidArrow's upload issue only exists because of lack of informations. Once they know what's what, anybody can use version control.

 

We had that issue as well, working distributed (What Marc-Saubion explained) works fine with slow connection, but when working directly with cloud, we had a problem when our ISP's quota was exceeded and upload speed was 5mbit until the end of the month. My colleague couldn't submit changes because of that. It has a timeout or something and if it cannot upload in time it just fails, and that's weird.

 

It uploads just fine when the PlasticSCM client freezes (a think that happens multiple times per day) during the upload, which is just ...weird. I think the limitation is pretty arbitrary.

To rephrase the above a bit differently: I can't upload stuff over 10mb easily with plastic, unless the client freezes during the upload, which (luckily?) happen pretty often. Now that's a workflow.

I think not setting up our own SVN on a droplet was a mistake and we're paying dearly now.

(with that said, PlasticSCM is much better than Collaborate in that... it works, but its client is freezing and crashing and has way too many quirks for me to consider it to actually be good, it also often fails to detect moves, initial set up was a complete mess etc. The Unity plugin is also a complete joke. Still much better than Collaborate overall, but that's a really really low bar)

 

Did you try my advice @AcidArrow ?

About plastic freezing often, that doesn't ring a bell. I've used it on multiple computers and never had anything like that, Neither, did people who worked with me. you should ask on their forum so you can check is the issue is on your side.

 

Not yet, but Plastic people seem to think this is an issue that can be fixed maybe? https://twitter.com/psluaces/status/1351096206261432324

I'd rather not switch our workflow.

 

I'm so glad I took the time to help you so you can die on that hill...

To anybody else, contact support and act nicely.

 

1. I've been in contact with support on and off for over a month now. They had already suggested switching to a distributed local repo, but for reasons I won't get into now, that workflow won't do for us.

2. It seems to happen exclusively with a Mac, which further supports this not being by design and it being a bug.

3. I haven't been told by PlasticSCM that it's by design, it's just that *something goes wrong* and chances of the thing going wrong are greatly increased by my slow connection. At least as I understand it.

4. So, if this is a bug they can fix, (and they'll release a potential fix in the next version of the client, so it may have already been fixed as we speak), and especially if it's not a bug that's super specific to my situation and it's something that other people stumble upon, then they should fix it and so no one else will need to contact support for this issue, because there won't be an issue.

I do not understand why you think this is a bad thing, and why instead of them fixing it once, you want multiple people to implement workarounds forever?

 

I don't think it's a bad thing, I'm just aware that there is a cost vs benefit behind every bug fix / feature and that you shouldn't expect this one to be a priority.

In this instance, I know that this issue also exists (or existed) on collab while it doesn't happen with software that works distributed like Git. This not being an isolated incident tells me that it could be more complicated to solve than it looks. Considering that I reported that same bug two years ago and they didn't fix it, there must be some truth to this.

I also take into account that the people who bring the most money to Plastic are professional who are very likely to work distributed and with a decent bandwidth, so users who are not affected by that issue. If you pigeonhole yourself with a niche workflow that doesn't work for you and doesn't bring them significant income, you will wait a long time for that bug fix.


Besides, there is so many times you can complain or ask for a favor before people stop listening to you so I prefer choosing my battles and concentrate on things that will benefit me on the long run.

 

For what it's worth:

1. I haven't had this issue with Collab (I've had every other issue imaginable, but not this one).

2. I am not 100% sure if we're talking about the same issue, since the one I want to get fixed seems to be Mac only: On a similar (if not slower) internet connection, another teammate with a Windows machine, has never had this issue.

3. Supposedly they fixed this issue in the next upcoming version of the client, so there's that.

4. After years of using Unity I have learnt that making a fuss is the minimum requirement for getting bugs fixed.

5. I believe that if I stick around, I should keep fighting battles, otherwise I should leave. So if we're going to continue using PlasticSCM, I expect silly stuff like this to get fixed (or I should at least get a decent explanation on why it's by design). Otherwise there is no point in using that service and I should have bitten the bullet and set up our own SVN server. Same with Unity, the day I stop complaining about things that bother me about the engine, is the day we move to Unreal.

6. We should have left Collaborate years ago, (I thought I could win that battle, but I couldn't), you were right about that when you told me a while back.

 

We are currently looking at paid version control for unity and to summarize what i read (mostly from here) very very briefly

Collaborate
Pros - Space calculated based on project size, history does not count towards space limit. Ok as version control for single developer projects.
Cons - Buggy as heck both to use as a team and even seems difficult to disable once enabled. Also seems to be updated irregularly, last update looooong ago based on release notes on this forum (it is abandoned?), questions on the forums mostly go unaswered.

PlasticSCM
Pros - decent integration, minor squiggles and bugs for niche workflows, still early in terms of integration so should get better (theoretically)
Cons - History counts towards space limit

Conclusion
Host your own gitlab/svn instead

Is this what i am seeing based on the discussions here?