A simple diff tool is certainly possible. In fact, you could probably do it through py/RNA alone. Of course, patches would be a bit more complicated to support, but could be doable (through RNA, you couldnt do it by patching the DNA data itself, not even in a text form, because there is no such thing as a robust .blend validator) On Dec 2, 2013 11:42 PM, "Nicholas Rishel" <[email protected]> wrote:
> There used to be a page on blender.org that covered the .blend file > format. > Unfortunately it did not make the > transition< > http://www.blender.org/development/architecture/blender-file-format/>to > 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 <[email protected] > >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 > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
