[Bf-committers] Gooseberry VCS?
rishel.nick at gmail.com
Tue Dec 3 07:42:29 CET 2013
There used to be a page on blender.org that covered the .blend file format.
Unfortunately it did not make the
the new site and I haven't had the time to check if it exists in the
wiki. But if my memory serves right it was implied that current design
would not be hard to translate to readable text - mentioning possible
benefits of using conventional VCS.
A working example of this exists with Unity3d which can save .scene files
as either binary or forced text. I have found this very helpful due to the
relation between objects in a scene and their associated scripts being kept
in sync between branches, but I'm not sure whether an analogue for this
exists in animation pipelines.
On Mon, Dec 2, 2013 at 8:16 PM, Gavin Howard <gavin.d.howard at gmail.com>wrote:
> Hey all,
> Right now, I'm listening to the Blender Podcast Episode 27, talking
> about the upcoming Gooseberry project, with its "distributed studio"
> requirements. With those requirements in mind, I thought I would again
> bring up a suggestion I made a long time ago.
> This suggestion is based on the fact (or myth, whichever is the case)
> that blend files are merely a "binary dump". Because Gooseberry will
> require coordination with studios across the globe, I think that
> implementing an internal "version control system" specifically for blend
> files would make it MUCH easier to manage all of Gooseberry's assets.
> In my mind (twisted as it may be), I see it using Git-like algorithms.
> Because blend files are binary dumps (which as I understand it, means that
> each section, or property in the file is separate from the others), it
> would generate diffs based on different sections. For example, say we have
> a blend file with a model and a material. The artist takes the file,
> changes the material, and recommits the file. The diff would show that only
> the material changed.
> Obviously, artists make a lot of changes between uploading, so that
> may not be entirely feasible. However, if we were to add the concept of
> "micro-diffs", that might help. In my mind, a micro-diff is ONE change
> only, and a diff would be a list of micro-diffs. (This actually could also
> help clean up the undo/redo system too.)
> Of course, I have a lot more in mind than I'm saying, but before I say
> more, I want to hear devs' opinions. If this is really not feasible, I'm
> fine with that. I know that I don't understand even a sliver of what goes
> on (as demonstrated when I failed this summer in GSoC). But I wanted to at
> least get it out there and see what real devs think. Thanks!
> Gavin Howard
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers