Storage space and exploding costs compared to Collaborate

I was just in the webinar about migrating to plastic and there was one point which is really important and people should be aware of regarding storage space and costs.

Regarding the costs for cloud space there is one important difference between Collaborate and Plastic, while Collaborate only considers the space used for the latest version of your project Plastic takes the whole space for the complete repository (not only the latest version!) in calculation.
This is even getting worse when you consider that Plastic doesn't store the deltas of files in the cloud, but (compressed) copies of the whole files.
So if I got this right and you make for example 5 checkins for a 1gb file (for example level data) this will use 6gb of data. As far as I understood this files will be stored compressed so it will probably less depending on the compression rates of these files, but for binaries I guess you still end up with about 3-4 gb of cloud space for 5 checkins in this example.
So imagine a working environment in which your artist make daily changes and checkins..
This also effects repositories which are migrated from Collaborate to Plastic btw!

If I got this wrong I would be happy to hear about it.. I like Plastic a lot, but this seems to be a big bummer for me.

 

Hi @marie-unity,

thanks for your quick answer. This sounds like a fair solution for users migrating their existing projects but I still have problems with the situation about new projects.
I think and feel like it must not be a regularly task cleaning up and removing old versions from a CVS, this sounds wrong. I want to have all the version available until the project is finished and I can put the project away. The problem is not having a lot of different versions even with just small changes in the files (thats what a CVS is meant for). Its more that Plastic stores complete copies of the files instead of just the changes. I can understand that this was a design decision to keep Plastic fast, its (like often) storage vs. speed.
But perhaps you can come up with some better ideas, for example like just keeping complete copies of the files from the last 2 weeks or last 10 changes or from a branch and after that just store the differences, etc.. so Plastic will still work fast for most of the time when you deal with daily work and only become slower when you go back to older versions, etc.. Just an idea.
I am afraid that the storage space required can grow really fast the way it works now (do you have some numbers of some real projects how this develops, that would be interesting), but when I consider how often our artists check in graphics and level data.. puuh.. but perhaps I am the only person seeing a problem here.

Thanks for your quick answer and the very nice webinar!
Best regards,
Marco

 

Also, keep in mind that this whole crediting scheme applies only if you still used that crappy collab system at the time of migration. If you had enough and moved off of the platform in order to be able to work actually and you had extra storage space on your Unity account, you can kiss it good bye. Only your usage counts, not what storage space were allotted to you.
(If you had 25Gb of space, but your active repo was only 1Gb at the time of migration, you won't ever get the 25Gb back)

 

From my personal experience I can only say that Plastic's deal has always been fair due to the incredible storage performance. I can't exactly tell you any ratio for a 1GB file, but my company has been hosting multiple large projects in the cloud and was working on them for 6-8 months each and the overall compression ratio is really good.

For example, we have a working copy that is 6 GB large and the used cloud storage is 5.1 GB (including history). We also have a 20 GB working copy with many large (600 MB) PSD binary files that were edited by multiple artists daily. The storage is currently 67 GB. I feel that's absolutely fair especially if you compare Plastic Cloud to other hosting services. Bitbucket with Git or previously Mercurial would exactly double your storage use if you moved the root folder for example or simply would use a much bigger proportion when editing binaries, while Plastic is very efficient about tracking moves and compressing binary blobs).

But btw, I would always recommend saving on your own space anyway, because its no fun downloading 50 GB via a non-optimal internet connection or simply because it makes lots of tasks more tedious or has high hardware requirements (copy paste or automated disk backups, killing Unity's library folder because of some corrupting bug, simply dealing with RAM overhead of large PSD files etc).

 

Thanks for your insides this makes me a little bit more optimistic about it. I will give it a try anyway because I really like Plastic and hopefully not be disappointed.

Thanks,
Marco