You need to log in to create posts and topics.

Set versioning limit for assets/scenes

Hello,

As project progress, multiple version are created and then never used again. Hence when the project is finished the folder size is very large. Just finished a project and the folder size is 239GB. If there was an option to set a maximum number of version an asset/scenes can have, this will help greatly with archiving projects and disk space. This is would be mainly assets and scenes and not for render files like exrs or tiffs.

Example: PROP_X is set to a limit of 20 versions. As you progress you can mark files that you don't want overwritten, so it will version up from there. Once the limit is hit, it will ask if you want to overwrite it or version up. If you version up then it goes to version 21, this is the new limit. This will make it more flexible.

Hope that makes sense?

Cheers

Femi

Hey Femi,

saving disk space is a topic with many different philosophies. Personally I prefer to never overwrite a version, but instead to increase the version number and eventually delete old versions if necessary. But it's always good to have different options.

One question to your explanation:

So if I create 20 versions of an asset and I mark v0005 and v0010 as locked/non-overwriteable. The next time I export a message would ask me if I want to make a new version or overwrite. When I choose overwrite, would the new export use v0011 or v0020?

Hi Richard,

yeah options are good.

So if I create 20 versions of an asset and I mark v0005 and v0010 as locked/non-overwriteable. The next time I export a message would ask me if I want to make a new version or overwrite. When I choose overwrite, would the new export use v0011 or v0020?

The new export will use v0020. Then if you lock v0020 the new version will be v0021. Then if you do a new export it will use v0021.

Does that make sense?

Cheers,
Femi

Yeah makes sense now. I'll add it to the feature list.

The basic functionality shouldn't be to hard to implement. But it gets trickier when the local/global project folder is enabled for the project. Some people may have 10 local versions and then another artist creates 20 new versions in the global project folder. Then the first artist has 30 versions even if the limit was 20. So there are a few special cases that need to be considered.

Hi Richard,

I was wondering but, wouldn't it be better to remove the concept of Local/Global project, and go for an arbitrary system where the user/studio can define as many project as he want, and tag them as 'global', 'local', 'render', 'archive', 'custom' with each tag have some functionnality, and each project having their own color/preference ?

I see that exporting a task of saving a new version of a file have a checkbox 'local', maybe having a droplist would give more liberty ?

and then you could implement a feature to transfert  a file/job to another project (like archive).

that sound like the most viable option for me, I would actually need more than 1 'global' project, because it just hard to decide what should be shared accross everyone, and what should be shared with the renderfarm.

Very interesting idea. That would open up a lot possibilities. For example you could create a "library" project and export all you asset to this project. When you are working on multiple animation projects you could add the library project to the current animation project. Then you would have access to the same assets in all your animation projects.

And for archieving and renderfarms it would be useful to.

The only little drawback I see here would be that it could make Prism a bit slower. The Project Browser need to search 5 or more projects to list all scenefiles instead of currently only two locations. But that's up to the user how many projects they want to have active at the same time.

The local/global project is used in many places in the current code, so that's not an easy change, but I'll add it to the list.

for the speed concern, I'd recommend looking at doing asynchronisation search, and doing directory discovery only when it required

 

for exemple, it not required to look up at every single available folder in a project if it won't be displayed on screen.

and any information like counting how much asset are present can be done by doing a asynchronous operation, the information would be dispalyed as 'loading' without blocking the main app!