[Data usage optimisation.]

Following multiple discussions about that feature and my experiences with Plastic and Git over the last years, I've listed what I think we'd need in order of importance

The main feature would able us to clean changesets that aren't merges or labeled (like the "only relevant" feature looks like).

Important

• Block that feature from non manager users.
• Keep all logs forever.
• Be able to revert that process during the following month so it's not risky to try it out.
• Limit cleanup to changesets older than x days.
• Add rules* so some files aren't affected and keep their history no matter what. 
   

Less important.

• Show the cleaned changesets in the main interface with a 50% opacity to avoid confusion.
• An option to delete previously deleted big files from history. (for example, if I replace a big TGA texture with an identical but lighter PNG)
• Automate the process so the cleanup is done after x days or x changesets.
• Add rules* so some files never have a history or only x versions.
• Allow users to cleanup a branch once they are done with it.

*rules based on file name, extension, size, parent folder...

Pricing would be based on how much data is effectively available each month. So for example, if the feature was used to cleanup my repo today, I'd pay the usual price this month an the next since the backup will still be accessible, and then see the effect on the price once that data is gone. I would then see my bills go up if I've worked on big files but this would only be a temporary bump and not a permanent cost.

 

Here are some default settings I would recommend for Unity users. Feel free to add suggestions.

• Always keep history : files that aren't in the /Asset folder.
• Always keep history : .cs .prefab .txt .meta .json.
• Always keep history : files < 50KB
• Never keep history : files named "LightingData.asset" or .psd.
• Delete from history after x days if deleted. File > 50MB and .tga , .wav, LightingData.asset.

 

I hope we can see that happen soon.

[Data usage optimisation.]

Glad to see this feature starts getting some attention and I hope we can get some news about it from the Plastic team.

One thing I'd like to address is that we need to keep the meta data. The main reason I don't delete my old repo and start fresh is that, while I'll unlikely to need the data after a year, I could still need the full history for legal reasons.

Keeping all the logs is like having a dashcam for work. It can save a lot of trouble if there is some kind of disagreement and should be kept a few years.

[What are Check Out benefits?]

Manually checking out can be confusing. Unity should make it automatic and transparent for the user.

[Repo Clean up: Deleting old changesets, is it possible?]

I'm currently working with a team using Git. There is an interesting feature called squash that Plastic could use for inspiration.

You work on a branch, do your thing that can include changing 3GB of texture everyday and, once you're done and you merge on Main, you have the option to squash your branch into one changeset.

This way, you can always get back to it but only keep the result and not the whole history. In the end, your history would look like you use the "only relevant" display option. All the important steps are still available but not the everyday changes.

 

One thing though, I'd like to keep the commits meta data. even if we squash a branch, we can still need that history as proof of work in case of a legal disagreement.

[Data usage optimisation.]

Hi.

Now that you've been bought by Unity, my feature suggestion might be less of a niche market.

There already some user concerns about this because Collaborate has a different policy for Data storage. https://forum.unity.com/threads/announcement-plastic-scm-joins-unity-here-is-the-collaborate-to-plastic-scm-migration-guide.953252/#post-6222609

I hope that features can be done. 😀

Thanks

[I'm stuck with no way out.]

Probleme solved thanks to Plastic's responsiveness and good support. 👍

Here is how it was done for people who'd need it. Close Plastic. Open your project folder and locate .Plastic (it's a hidden folder). You'll find some files containing the data like your current merge. delete the file causing an issue. Restart Plastic and go to the changeset you wanted.

I'm not sure which file to delete keep in mind this is a risky solution, so in fou have doubts, I'd recommend contacting support about this.

Hopfully, we can get an option to clean these files from the main interface and not worry about this anymore.

[I'm stuck with no way out.]

Hi.

I'm stuck in an infinite loop.

I think this issue has been caused by some files with a ridiculous long name (from an asset that I bought). I deleted these files but plastic keeps trying to track them or something and won't let me get back to work.

I currently can't get my late changes because there is a merge pending.

The merge is empty, so I can't do anything about it.

Reverting my local changes doesn't work because of an error (certainly caused by the long name file).

What can i do?

This is not the first time I'm stuck in a similar situation. We need an option to switch to a changeset and forget about whatever was causing an issue. Even when I manage to find a solution, it's way too complicated to deal with it. In this instance, I'm stuck with a merge I didn't even want in the first place.

Can't we get that option? I understand you want to avoid users losing data but in my experience, dealing with an obtuse version control is much worse. You could baby-proof it with a window asking the user to type "I understand i will lose my local changes but this is an emergency" to use it.

Thanks

 

[I need urgent help. Plastic is locked because of a missing changeset.]

It worked. 😀

And it didn't have to redownload the whole project. It went to my chosen changeset.

Thanks again for your help and I hope this will be usefull until you fix that bug.

[I need urgent help. Plastic is locked because of a missing changeset.]

Hi Pablo and thanks for answering me on Sunday.

So I tried and do get the "home changeset again" but it's the first one meaning Plastic is going to redownload my whole project. This is what I'm trying to avoid because I have a bad bandwidth.

I tried editing the selector to get to my targeted changeset but Plastic ignores it. Any way I can do that?

repository "MyProject@Myplasticlcoud@cloud"
  path "/"
    smartbranch "/main/Car Tournament Retrieval" changeset "435"        

PS: I do have an other instance of Plastic working at the moment (Making a new workspace from a local repo).

Edit: re reading your message I understand it should go to my chosen changeset. Trying it and hoping I won't have to redownload the whole thing.

[I need urgent help. Plastic is locked because of a missing changeset.]

Hi.

I'm currently locked by Plastic because of a deleted changeset. I have some local changes that I cannot undo or commit because the home changeset has been deleted from an other computer and there is no option to handle that situation. I'm stuck because of a deleted empty folder. I can't revert it, I can't commit it, I can't shelve it. I tried to create an other folder with the exact same name and it doesn't work either because Plastic think it's a new one. I tried editing the plastic.selector file to "manually" get to a valid changeset but it does nothing.

To put is simply, nothing works because of that missing changeset and Plastic doesn't know how to handle that situation. Is there any way I can force plastic to change the home changeset?

Thanks

[Plastic keeps asking for my encryption key.]

This is an issue I've had more than once and that keeps getting back.

I'm currently reverting to a changeset and plastic keeps asking for the encryption key. I see on the progress bar that it works but then it asks for it again and again. I have no idea if I it doesn't recognize the key or if it's unable to memorize it.

In any case I'm stuck because I can't humanly spend days entering that key hoping it might work.

Can somebody help with this?

Thanks.

[Data usage optimisation.]

On 3/20/2019 at 9:50 AM, psantosl said:

My question is: why do you checkin the lightmap if it can be rebaked? Because it is easier to share it through Plastic SCM than actually using other mechanism, correct?

Yes. I come from Unity's "Collaborate", a pseudo VCS tool used to work as a team. If I'm not mistaken, it only kept 10 last versions of each files and that was enough for us.

Understood.

 

Of course this means you are in single branch, right. How would this work with multiple branches?

I'm not sure about that. I don't have an extensive branches experience.

The "super changeset" can be simply a labelled one. You know, you can label changesets.

I did not but I'm checking this out. Thanks

So the rule would be something like:

Keep only 3 versions of LightingData.asset.

Keep only N versions of files > that size except if they are labelled.

Yes, that would work. Though we would need a label preset option to avoid human error.

I'm actually very interested on this topic, because it makes a lot of sense for us to add extra features for teams using Unity.

I'll add more people to the conversation.

 

I'm glad this is welcome. I think you have some business to gain from unity's users since they screwed up badly with their own service (Collaborate). It was so neglected and full of bugs that it became unusable. I subscribed to your service in an emergency and believe you should offer a unity preset plan because that's what I was looking for.

[Data usage optimisation.]

Hi Psantosl and thanks for that quick reply.

Yes that is correct.

A coworker and I are currently working on a large game level. The scene file is 130MB and it's lightmap 1.7GB. We re-bake the lighmap once or twice a week and it's only on the cloud server so it's shared on our computers. We don't need versioning on it since it can always be re-baked. The scenes are sent back and forth to each other all the time so they can be uploaded +5 times a day which is more than we need for long term backups. As you can see, this can pile up quickly for minor changes.

The lightmap is easy to deal with. Unity creates a file always called "LightingData.asset" so all we would need is a rule for these files to only keep N revisions as you suggested.

For files like my scene, above a certain weight, it's a bit trickier. A solution would be to have an other rule to discard chosen assets after x days, but because we might need to get it back to a previous version after that date, we could set an exception with a milestone. A milestone would be a "super-changeset" where that rule doesn't apply.

In practice here is how it would go. We're working as usual and set an occasional milestone each week when we're satisfied with our work. At this point we can always go back to any changeset because recent data is kept on it as long as it is not a lightmap. Six month later, a client asks us to revert some changes on that scene we were done with: most of the scenes data was erased after x days to save space but we have the milestones which is enough for what we need.

 

I understand my request might be unusual. I'm working on a big unity project to make multiple mini games that share the same assets so I'm not creating a new repository each time a create a new one. That means the data I'm currently pilling up could follow me for the next years and would cost me a lot on the long run. So while it's not urgent, I hope we can find a solution to avoid hoarding too much data.

Thanks

[Data usage optimisation.]

Hi.

When I started using Plastic few weeks ago, I was pleased to see my usage on the cloud server was less that the assets on my hard drive but this has shifted the other way since. I understand plastic also stores previous versions of my files: if I save often update a 1GB psd file for example, it's fair that it uses more than 1GB on the cloud. That said, I know I don't need to keep previous versions of files like lighmaps data and was wondering if there are some optimizations I could use so I don't end up using 3x my local data on the cloud.

Is that possible?

Thanks

[UnityYAMLMerge.exe - Error in merge tool]

So, i went back home and tried a merge with my other computer and it worked fine.

We also installed a the latest Unity version and linked to a fresh install of UnityYAMLMerge.exe in case the existing one was corrupt but we get the same error. I think Nicolas issue might come from his computer.

If anybody as a suggestion, they are welcome.

Thanks