[Bf-funboard] Built-in version control

[Prashant Sohani]

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
>