[Bf-committers] Gooseberry VCS?

[joe]

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" <rishel.nick at gmail.com> 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 <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
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>