[Bf-funboard] Built-in version control

[Prashant Sohani]

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
>