I hear that term referred to as “bubble up” This is a good term. I’ve also heard of it as “trickle down”. I suppose it depends on how you envision the dependency graph in your mind; either as starting from the root of a tree heading up towards the leaves or heading down along its roots. :)
On 2 October 2014 09:59, Marcus Ottosson <[email protected]> wrote: > Does that at all fit into what you are talking about? I could be off base. > > Yeah, those are some of the scenarios I’d expect this feature to fulfill > and yeah, it is quite involved and should probably involve a separate, > dedicated versioning library. > > For the evaluation of versions, such as being either “latest” and > “approved”, I’d assume the presence of other pipeline tools as it’s outside > the scope of Pyblish. Physically updating an asset is most likely also > outside this scope too. > > However, I would expect such a process to ultimately produce one or more > absolute paths to files in need of updating. This is what Pyblish would use > to ultimately produce a new version and allow users to monitor the results, > along with distributing the action to a farm or a background process. > Pyblish is ultimately about quality controlling assets. > > In practice, I would imagine seeing an extension to Pyblish that > implements rudimentary versioning, so as to get the feature off the ground, > that would ultimately be replaced with whichever library a studio is > currently using (if any). > > > On 2 October 2014 09:34, Justin Israel <[email protected]> wrote: > >> I hear that term referred to as "bubble up". I suppose there are a few >> different scenarios depending on how you represent and manage your assets. >> If your assets capture and store the references to its dependencies in a >> version-specific way, then updating one dependency might trigger the others >> to need to republish. Or, if your assets evaluate dynamically at runtime on >> concepts such as the "latest" or "approved" or "official" type aliases, >> then they can always pick up the appropriate reference at the time they are >> used. An example would be a scene asset which contains 2 character assets. >> If the scene refers to the characters by way of an alias to the "latest", >> then each time the scene is opened/rendered it would pick those up. Where >> as if that scene referenced specific versions like "char1_v2" and >> "char2_v3", then a bubble-up process might be necessary to republish the >> scene with new references (or a manual update triggered within the scene). >> >> Does that at all fit into what you are talking about? I could be off >> base. >> >> >> >> On Thu, Oct 2, 2014 at 8:51 PM, Marcus Ottosson <[email protected]> >> wrote: >> >>> Dependencies and Cascading Updates >>> >>> Hi guys, >>> >>> I’m looking for another pair of eyes on a potential feature. >>> >>> [image: Inline images 1] >>> >>> In short, it involves automatically updating assets A, B and C which >>> depend on another asset D, when asset D is updated. >>> >>> - https://github.com/abstractfactory/pyblish/issues/113 >>> >>> Questions >>> >>> - >>> >>> Is this a problem worth solving? >>> - >>> >>> Have you encountered it before? >>> - Have you solved it before? >>> - Can you spot any issues? >>> >>> Best, >>> Marcus >>> >>> >>> On 30 September 2014 18:38, Marcus Ottosson <[email protected]> >>> wrote: >>> >>>> Hey Asi, >>>> >>>> I think you forgot to attach the diagram. >>>> >>>> I find it helps leave the little technical details for a second >>>> >>>> Not sure I can get less technical than the animation of the end-result. >>>> :) >>>> https://github.com/abstractfactory/pyblish/issues/99 >>>> >>>> Is there anything in particular that you find fuzzy? >>>> >>>> Best, >>>> Marcus >>>> >>>> >>> >>> >>> >>> -- >>> *Marcus Ottosson* >>> [email protected] >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBVNEGRk2XvUTn6eDw4-biefv66BY60prSejWzRNmovzg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBVNEGRk2XvUTn6eDw4-biefv66BY60prSejWzRNmovzg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0zdoGyZ43bLzZSE16s4Npru5NTwkickh2uiftZF%2BUsww%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0zdoGyZ43bLzZSE16s4Npru5NTwkickh2uiftZF%2BUsww%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > *Marcus Ottosson* > [email protected] > -- *Marcus Ottosson* [email protected] -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAA1Mpz15R3nLDGWgci-W804UKCxC-cpH3GpsN1Ckeu0A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
