[Bf-funboard] Built-in version control

Campbell Barton ideasman42 at gmail.com
Sun Jan 13 05:15:07 CET 2013


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


More information about the Bf-funboard mailing list