[Bf-funboard] Built-in version control

Shrinidhi Rao shrinidhi666 at gmail.com
Sun Jan 13 10:46:34 CET 2013


i wouldn't suggest integrating a versioning system into blender itself ..
it is best left to the pipeline TD in a studio . the best solution is to
provide the APIs needed to implement such tools.





On Sun, Jan 13, 2013 at 2:45 PM, Prashant Sohani
<prashant.sohani at gmail.com>wrote:

> Another somewhat related aspect would be to let the file browser also blend
> files over a network, say via HTTP.. for instance I'd like to often use
> materials from an online repository located at say,
> example.com/materials.blend . I think there is a Blender addon that
> connects to some online materials library, but if the server backend could
> be simply a publicly hosted blend file that contains all the offered
> datablocks..
> But again, accessing such a file over HTTP means transferring the entire
> file contents rather than like just an index of the offered materials..
> need to think of a way to achieve this.
>
> On 13 January 2013 14:38, Gianmichele Mariani <g.mariani at liquidnet.it
> >wrote:
>
> > I agree with Campbell here. Making this kind of choice for the user is
> > limiting and most often than not, everyone wants to build his own
> pipeline
> > for asset management, cause it's not just about versioning assets, but
> > there's a whole load of other things that need to converge or being
> > integrated (tracking, dependencies, etc.)
> >
> > On Tube Bassam is using sparkleshare that combined with some custom
> tools,
> > lets artists and in particular animators, deal with only the files and
> > textures that they need without having to rely on huge databases etc.
> >
> > Probably the best approach would be to give the users the tools to more
> > easily integrate a custom pipeline. Like the ability to easily retrieve
> > dependencies of a certain asset in  a scene (model->textures->armatures).
> >
> > .Gian
> >
> > On Sun, Jan 13, 2013 at 7:31 AM, Prashant Sohani
> > <prashant.sohani at gmail.com>wrote:
> >
> > > As you mention, it might be better to let users externally choose and
> > > manage their own blend file versioning setup.. some people may be
> dealing
> > > with only low-complexity projects where they'd find it easier to just
> > > create timestamped copies as needed, some may want git svn etc..
> > >
> > > A different approach is to focus on create a versioning system for
> > certain
> > > datablocks within Blender itself..
> > > For instance, take a material node compositing setup.. (call it
> > greenGlass,
> > > say) on which I've been working for quite a while.. or maybe a fairly
> > > complex mesh object, say a sculpture.. again, it'd be desirable to be
> > able
> > > to save intermediate 'good' checkpoints as an easily browseable
> sequence
> > of
> > > datablocks .. perhaps simply name them greenGlass.v1, greenGlass.v2 and
> > so
> > > on, each time appending at the head of the list while making a fresh
> > > commit, so that the current git-like "HEAD" is always called
> greenGlass.
> > > And then, a nice click-through interface similar to my patch there will
> > > enable the users to quickly navigate the commit history.
> > >
> > > Maybe there could be an option in the user preferences, where the user
> > can
> > > specify whether at the time of saving to blend files, they want to save
> > > only the HEAD datablock, or whether they'd like the commit-list [if not
> > > tree] to be also saved.
> > >
> > > This still leaves the question of merging, and possibly duplicating
> just
> > a
> > > selected branch of a previously committed nodetree.. I personally don't
> > see
> > > myself needing to merge two versions of the same datablock.. but I'm no
> > CG
> > > artist (yet) :D
> > >
> > >
> > > On 13 January 2013 09:45, Campbell Barton <ideasman42 at gmail.com>
> wrote:
> > >
> > > > On Sat, Dec 1, 2012 at 6:06 AM, Prashant Sohani
> > > > <prashant.sohani at gmail.com> wrote:
> > > > > Yes.. at the moment, trying to diff or merge the actual file data,
> I
> > am
> > > > not
> > > > > even thinking about.. I am still unsure of how much version control
> > > > Blender
> > > > > should really be doing, and if it may be better to let the user use
> > an
> > > > > external tool of his choice, such as git.
> > > > >
> > > > > Another thought is to handle the versioning of datablocks in a
> .blend
> > > > file
> > > > > somewhat like git objects.. indeed, a Git repository represents a
> > tree
> > > of
> > > > > commits just as a blend file of datablocks and structures.. mildly
> > > > poetic,
> > > > > but I don't know where to go from there.
> > > > >
> > > > > For the moment, I would keep my focus on file-level versioning,
> > > > navigation
> > > > > and branching (no merging), and taking the above script to a more
> > > > > consistent, complete stage.
> > > > >
> > > > > Regards,
> > > > > Prashant
> > > >
> > > > Versioning blender projects is an interesting problem, however Im not
> > > > sure it has to necessarily be integrated.
> > > >
> > > > The problem with integration is you'll likely end up sticking to a
> > > > single VCS/DVCS (svn/git/bazaar... etc), maybe thats OK... but a
> > > > constraint and you end up making this choice for the user.
> > > >
> > > > The way blend files are basically a memory dump makes merging changes
> > > > to blend files quite tricky, perhaps if someone changes vertices in a
> > > > mesh and another person adds a new mesh - this could be merged, but
> Im
> > > > not sure its really worth spending a lot of time to get this working.
> > > > I think its more realistic to have commit logs report on what changed
> > > > in a commit - so you could see the datablocks that were
> > > > added/removed/modified on each commit.
> > > >
> > > > In practice I found its best just to split up blend files where
> > > > possible to reduce the chance of conflicts since only a few artists
> > > > will work on each one.
> > > >
> > > >
> > > > For collaborating on projects online blend files can get really huge
> -
> > > > 100-500mb, not to mention textures, sound etc.
> > > > It would be interesting to investigate a way so artists can
> > > > 'subscribe' to assets.
> > > > This way - an animator doesn't have to download composting plates,
> > > > modeler doesn't have to download soundtrack or animatic,... etc.
> > > > The dependencies for these assets should be calculated automatic but
> I
> > > > think some integration would be needed with source control so you
> > > > could avoid checking out entire texture paths when only a few are
> > > > needed.
> > > >
> > > > --
> > > > - Campbell
> > > > _______________________________________________
> > > > Bf-funboard mailing list
> > > > Bf-funboard at blender.org
> > > > http://lists.blender.org/mailman/listinfo/bf-funboard
> > > >
> > > _______________________________________________
> > > Bf-funboard mailing list
> > > Bf-funboard at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-funboard
> > >
> > _______________________________________________
> > Bf-funboard mailing list
> > Bf-funboard at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-funboard
> >
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard
>



-- 

regards
- shrinidhi


Even god fails to understand a human until his death!
http://www.linkedin.com/in/shrinidhi666
https://github.com/shrinidhi666



<http://www.imdb.com/name/nm3025616>


More information about the Bf-funboard mailing list