Plastic SCM vs Unity Collaborate - my experience

I switched from Unity Collaborate to Plastic SCM about a week ago. Here's my experience so far:

The good:

• No need to download and maintain another Unity asset, it seems to be either integrated into Unity, or comes with the base Windows download for the standalone Plastic SCM application
• Integrated with the editor: see which files are changed, etc.
• Branching
• 'Professional grade' version control, with all of the advantages that that entails
• Cloud hosting and storage built in. No need to manage your own cloud storage.
• No 'checking for changes'.
• Downloading an existing project via Unity Collaborate seemed to take hours just to uncompress the download, compile all scripts, etc. This stage seemed to take only minutes in Plastic.
• Seems to handle giant files just fine, no need for separate art storage buckets.

The bad:

• No Unity-specific documentation, just a few old Youtube videos.
• Need to setup ignore settings BEFORE you begin to use Plastic, otherwise your wannabe-ignored files will remain in the project forever.
• Even though all remote users had the full project (40gb), we couldn't figure out how to integrate the project with the local version, so everyone had to redownload the project, costing us about 2 days of productivity. Support was unhelpful.
• Generally a very steep learning curve
• This could be solved via proper ignore settings, but Unity projects have about 25% of the project as 'cruft' metadata by size, which is compressed or ignored by Unity Collaborate, but not by Plastic.
• Unity Collaborate seemed to provide basic scene merging, examining which gameobjects were changed and only flagging conflicts at that level, otherwise allowing the scene to be merged.

Who is Plastic SCM good for?
Teams of 2-10 people, who are working on a commercial product, need branching, and can deal with the steep learning curve. Teams who don't want the intellectual overhead of managing Git, and want a version control software specifically designed for games and integrated with Unity.


Vs Git
I havn't used Git, but my third-hand knowledge of it is that you need to manage your own storage, your client, and there are difficulties with scripts and art in the same buckets. You pay more to use Plastic, but all of this is handled for you. However, Git might still be better for bigger teams, with the economies of scale to manage their own version control in-house.


So, who is Unity Collaborate useful for?
In my opinion, its useful for a solo developer as an upgrade to using Dropbox to manage your backups, and with some basic revisioning. That's it. I would NOT recommend using Unity Collaborate for anything more complex than that, including for more than one person working on the project. All up, I've lost about 2 man-weeks of work due to Unity Collaborate faults over the project life of my title, that could have been avoided if I used better version control in the beginning (less the time needed to set it up and learn it).

The basic scene merging that Unity Collaborate provides is also nice, but a professional studio should really be managing its project structure and file access regime in order to minimise conflicts anyway.


Summary: If you have any of these things planned:

• Post-release major updates to your title
• Multi-platform releases
• More than just one person working on the project

Do not use Unity Collaborate, instead invest the time in getting Plastic SCM setup in the beginning.

Future
Going forward, I would recommend Unity just retain Collaborate as a basic backup system. I don't see the point of having a more sophisticated Unity Collaborate product, when there are already good professional-grade version control products out there. Instead, Unity should just extend its partnership with Plastic SCM and make it the official solution for any teams that need something more sophisticated, and provide proper written documentation for users.

 

Thanks for sharing your experience, very useful.

 

Not all smooth sailing. Working with FMOD is a big problem.

Like most version control systems I guess, Plastic really needs a single expert user to set the project up correctly and guide all users through the correct use. Not easy to do for a remote team, which is possibly why the documentation is so focused on the local edition.

 

Ok, the newer version of FMOD solves the problem I was having.

Definitely setup your ignore files correctly at the start of using Plastic. Would be great if Plastic had a standard suggested list of ignore settings for Unity projects that you could select from.

2 users, 35GB of storage is $33/month. More expensive compared to Collaborate.

There's a definite learning curve but its working fine for us now.

 

Without ignore file: 39GB project
With ignore file: 22GB

Setup your ignore file correctly as your very, very first step! Its impossible to do it afterwards.

We just used this one for Git: https://github.com/github/gitignore/blob/master/Unity.gitignore

Without the correct ignore file, Plastic SCM will not work correctly with Unity, and you will face a lot of problems. Just opening the project in Unity will generate about 2GB ignorable of cache data.

 

I just found how you can do that.

Go to the workspace explorer and select whatever folder/file you want to ignore. Press "delete" and Plastic will ask you if you want to delete the file on disk or not. If you keep the file on disk, it will be back to a "private" file that you can put in the ignore list.

That said, I still agree with you. I also thought this was not possible while this could be a "right click/ignore" option.

 

Their videos describe how to start a project from scratch with Plastic SCM or how to connect to a project that's already in SCM. I can't find how to take a gigantic, existing project and convert it to a Plastic SCM project. Any tips or directions on that specific piece (besides getting my ignore file nailed down)?

 

You don't really "convert" the project. It's just your files and a plastic special file saying what files/folders are ignored.

Basically, you make a repo, create a new workspace for it. Copy paste your project in its and have it configured for unity so it will ignore some folders like the library. There is an option to do that automatically in the tips window with the owl.

 

Is Plastic SCM owned by Unity because they are pushing it on their own collaborate website?

 

yes

 

I'm a single developer, and Collaborate is OK, but I just switched to PlasticSCM because even as a solo developer, branching is really a must. Once they add branching to Collaborate, though, I feel like it'll be a serious contender. For now even as a single developer, I'd recommend Plastic. I'm glad Unity bought them too, because the prices now are great. Cheaper than github, google cloud, etc. It was pretty painless to migrate from Collaborate to Plastic using their wizard, too.

 

1. We've been waiting for branching 4 years : https://forum.unity.com/threads/collab-and-release-branches.502122/#post-3271388

Do not count on it.

2. It's not a serious contender, once your project size increases, checking for changes times hit 5-6 minutes and happen every 10 minutes.

3. The UI after many years of existing, is terrible. Want to go back to a much older commit? Well TOUGH LUCK. You can't skip pages, you can't search by commit comments. Even the site side of it has been abandoned : Want to know part of which commit is a certain previous version of a file? WELL TOUGH LUCK.

TL;DR Collaborate has been barely functional since its "release" and Unity has been daring to charge for it.

People on the forums say I'm pretty negative towards Unity, and yes I have lost a lot of faith in Unity over the years and how they handled Collaborate is a huge part of that.

Do not use it.

 

I have used Collab, Plastic SCM and git.
Git is the clear winner (With LFS), other solutions are half backed.

I would probably use Perforce if working on an an extremely large and distributed project, for other (Team of 3 - 6), I would stick with Git.

 

What was your issues with Plastic?

I've used it in parallel with git and didn't see any major differences but it's on solo projects.

I tried Git + LFS few years ago and it was a total nightmare to setup. That's why I ended up using Plastic. I have good experiences with Git but on projects that were setup and maintained by a lead developer.

What dealbreakers did you encounter?

 

The Team wanted a cloud solution that can also handle CI/CD, Tests, PRs, etc.

Plastic Cloud needs to integrate with a different solution to handle CI/CD, and use APIs to do so.
PRs and Reviews are not the same as Git, and harder to do (At least from our experience). Setting a workflow that does not allow a branch to be merged unless it is reviewed was tough.
So taking beginners, we would need to train them in using Plastic and branching and reviews, we preferred to put the effort into training them in Git, which they can also use if their career takes them outside the game industry and they collaborate with other software projects (Where git is primarily used).

At the end of the day, it took less than a day to setup LFS + PRs Workflow and CI/CD (with github actions using game.ci).
Another point is knowledge gained in Git can be applied elsewhere.

 

Thanks for your anwser @jsaade-gc .

That confirms what I already thought so that's good news for me.

Do you know if there is a storage limit for Git-LFS? Back when I tried it three years ago, their policy was pretty opaque about this. Working on a giant project, I choose Plastic for that reason.

 

Ir depends on the provider. Microsoft Azure Repos offer un limited LFS space.

 

Yes, there are storage and bandwidth limits but you can buy blocks and expand it. If I remember correctly you buy LFS blocks of 50GB increments and around 500GB Bandwidth (per year) @ 60$ per year.

I would definitely not use Git / LFS for Large projects (TBs of data). I am pretty sure that it was not designed to handle such projects.

 

I am a solo developer using Collaborate as version control for a small project.

The problem with Collaborate is that it is not possible to compare a previous file.
You can compare the changes only with the latest version, but not with previous ones.
It is a very simple feature. It is not implemented as well as a restoration of an old file.

My second problem with Collaborate; since the launch is not working well or at all.
I am afraid to do a restore (it was unreliable in the past) and in fact, actually,
it disconnects, doesn't accept a push, or just prints nonsense on the console.

Collaborating is a good idea, poorly implemented, and difficult to trust.
For a solo developer, Collaborate V1 needs bug fixes and a few more features.
Actually, Collaborate V1 (version control) is not a nice feature that Unity can be proud of.

 

I really like colaborate , is it gonna shut down ?
we can only use plastic ?

 

https://forum.unity.com/threads/collaborate-will-soon-be-upgraded-to-plastic-scm.1188592/