[Bf-committers] Gooseberry VCS?

[Manuel Rais]

Hi there !

This is my first post here, so let me introduce myself quickly.
My name is Manu and i use blender since 2006 now (I began to work in 
2000 as a compositor). The community is great, and since I use it, 
Blender is becoming more and more powerful, more professional (now in 
the companies I use to work, they don't ignore Blender anymore, they 
watch it closely... really...).
I'm a lighting/compositing supervisor, TD (including pipeline...), 
developer and i've supervised the lighting and compositing of Babioles 
directed by Mathieu Auvray (a good friend of mine actually)... I've also 
managed other animation TV shows, feature films...
As discussed with Mathieu, I'm going to be a part of the french team for 
the Gooseberry Project and i'm very happy !

So, I guess the right way to create a new VCS for blender is to manage 
also binary files.
I use svn since many years now for my development projects (production 
tracking system, blender addons...) and it works very well with text 
files but unfortunately binary files are always committed entirely AFAIK...

Finding a solution only for blend files (such as save as a readable text 
file which is a good idea i think, for pipeliners, many other softwares 
have this functionality) is not sufficient. How about all the others 
binaries like images, point cache etc... ?
I didn't worked on any open movies, so i don't know which files were 
committed (only blends ? Images ?).

The diff tool is the right answer i guess but I really don't know if 
it's hard to develop, if it's possible... I've heard about a famous FX 
company in London who work(ed) on such a version control system, but so 
far I don't know if they use it or even if it's working.

A little off topic : I think there are many cases where a VCS has 
"issues" in a feature film production (such as : how do you manage 
modifying an asset who broke half of the projects, without creating a 
second asset file ?). A VCS is a very powerful tool but i think we have 
to improve how we use it... Maybe I'll begin a topic about that this week...


Manu
manu at g-lul.com

Le 03/12/2013 08:10, joe a écrit :
> 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
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers