What would be the best workflow in Tank to use versionless files. For example, if I publish a model 10 times to get
model.v001.mb
model.v002.mb
model.v003.mb
...
model.v010.mb
I want a file just called model.mb or something similar that is a copy or symlink to the version want everyone to use in production.
Would I just write a hook to copy the file or is there a different recommended way?
Hi!
Coincidentally enough, I just started a ticket on tank support about that...
Here is the thing I sent, let me know if this is what you think of :
We have an asset that will be used in 50 to 70 shots, in maya.
The problem is that every time we publish a new version of this asset, we have to open every scene to update the asset and save again.
(We know the animation will not change, and we just want to relaunch renders...)
In our previous proprietary pipeline, we were able to choose whether or not an asset would have versioning at publish. If it was not, it would be overwritten over and over. (with a snapshot-like thing for safety, of course)
Is there a way to do the same thing in tank?
I tried removing the version number (v{version}) in the template.yml, for "# The location of published maya files", but when I do that, the publish disappears from the tank menu in maya...
An alternative solution to this problem would be to be able to update the assets in a maya scene from outside of maya, with a function in shotgun that could edit maya ascii files, for example...
Same problem will go with animation files down the line, when a render scene is referencing a animation scene, if the animation change, I don't want to go back to the render scene and update, I just want to relaunch the render.
Thanks for posting! This has come up a number of times with testing clients, and I had been putting a proposal diagram together (attached) based on those discussions (as well as other similar pipelines I've encountered in the past). It would be great to get some feedback on the direction!
In a nutshell, the intent would be to configure and manage the "versionless" behavior through publish hooks as Chad suggests. The new multi-publish app would allow that behavior to be more transparent if desired, or it could also be added to the default scene publish hook so that it always happens. A combination could also make sense (i.e. the "pub" file/link can be toggled on and off through multi-publish, but the "latest" file/link always happens and is part of the primary scene hook). We may have to make some tweaks to the way hooks framework for the multi-publish app behaves as well as relax some core/engine restrictions that expect versions to better accommodate this workflow, so learning more about people's use case details will help us know what the right thing to provide is.
Also, Shotgun would need to have some schema additions to help support a workflow like this, so it could still track what's going on even if version numbers aren't being used by artists. We think it's important for people to still be able to backtrack and see exactly what's being used, if only for debugging purposes, and we don't want to lose key functionality like dependency tracking as those tools evolve within Shotgun and Tank. The initial design calls for additional path fields for each "versionless" designation a studio uses and a status to mark the "pub" version number. Some publishes may always have the additional path value (ex. "latest," since every publish will be the latest at its time of creation), but some may not (ex. a bad publish that never reaches the "pub status). With this approach, the thought is that we could also cover the history of the "pub" version number so that any publish with the path field populated would have at some point had that status, but there would only ever be one publish of a given type with that status for query purposes. This is where things start to get tricky, so again use case details will help make sure things are on the right track!
Anyhow, have a look at the diagram and let us know your thoughts. We'd love to collaborate with clients who want to experiment with this workflow and would be glad to help push through some conventions (like the Shotgun schema stuff) to help people move forward.
Ryan.
This sounds perfect to me... that's exactly what I'd like :)
Hi everyone,
Did this ever get implemented, or was there ever documentation on how to go about modding sgtk to do this? If yes please point me to the docs on the subject (which I can't seem to find via Google).
Cheers,
-DW
