[Bf-funboard] Built-in version control

Campbell Barton ideasman42 at gmail.com
Sun Jan 13 16:50:54 CET 2013


Hi, reply inline...

On Sun, Jan 13, 2013 at 8:15 PM, Prashant Sohani
<prashant.sohani at gmail.com> wrote:
> Another somewhat related aspect would be to let the file browser also blend
> files over a network, say via HTTP.. for instance I'd like to often use
> materials from an online repository located at say,
> example.com/materials.blend . I think there is a Blender addon that
> connects to some online materials library, but if the server backend could
> be simply a publicly hosted blend file that contains all the offered
> datablocks..
> But again, accessing such a file over HTTP means transferring the entire
> file contents rather than like just an index of the offered materials..
> need to think of a way to achieve this.

For this, it could be better to have some web front-end to the
repository, so you could browse the entire repo and see thumbnails for
textures and blends, maybe even see thumbs for each version (and
compare over time).

Such a tool could probably be setup to be VCS agnostic - add support
for many version control systems --- and preview different file
formats - though starting with blend files + images.

> On 13 January 2013 14:38, Gianmichele Mariani <g.mariani at liquidnet.it>wrote:
>
>> I agree with Campbell here. Making this kind of choice for the user is
>> limiting and most often than not, everyone wants to build his own pipeline
>> for asset management, cause it's not just about versioning assets, but
>> there's a whole load of other things that need to converge or being
>> integrated (tracking, dependencies, etc.)

Regarding making the choice of VCS for the user - I wouldn't want to
get caught in the trap of not even trying just because not everyone
will be happy with the technical choices made.
Perhaps its possible to make a really good system using one VCS and
others can be added later, or the system might be so good that TD's
set their personal preference asside and use it :).

>> On Tube Bassam is using sparkleshare that combined with some custom tools,
>> lets artists and in particular animators, deal with only the files and
>> textures that they need without having to rely on huge databases etc.
>>
>> Probably the best approach would be to give the users the tools to more
>> easily integrate a custom pipeline. Like the ability to easily retrieve
>> dependencies of a certain asset in  a scene (model->textures->armatures).
>>
>> .Gian
>>
>> On Sun, Jan 13, 2013 at 7:31 AM, Prashant Sohani
>> <prashant.sohani at gmail.com>wrote:
>>
>> > As you mention, it might be better to let users externally choose and
>> > manage their own blend file versioning setup.. some people may be dealing
>> > with only low-complexity projects where they'd find it easier to just
>> > create timestamped copies as needed, some may want git svn etc..
>> >
>> > A different approach is to focus on create a versioning system for
>> certain
>> > datablocks within Blender itself..
>> > For instance, take a material node compositing setup.. (call it
>> greenGlass,
>> > say) on which I've been working for quite a while.. or maybe a fairly
>> > complex mesh object, say a sculpture.. again, it'd be desirable to be
>> able
>> > to save intermediate 'good' checkpoints as an easily browseable sequence
>> of
>> > datablocks .. perhaps simply name them greenGlass.v1, greenGlass.v2 and
>> so
>> > on, each time appending at the head of the list while making a fresh
>> > commit, so that the current git-like "HEAD" is always called greenGlass.
>> > And then, a nice click-through interface similar to my patch there will
>> > enable the users to quickly navigate the commit history.
>> >
>> > Maybe there could be an option in the user preferences, where the user
>> can
>> > specify whether at the time of saving to blend files, they want to save
>> > only the HEAD datablock, or whether they'd like the commit-list [if not
>> > tree] to be also saved.
>> >
>> > This still leaves the question of merging, and possibly duplicating just
>> a
>> > selected branch of a previously committed nodetree.. I personally don't
>> see
>> > myself needing to merge two versions of the same datablock.. but I'm no
>> CG
>> > artist (yet) :D
>> >
>> >
>> > On 13 January 2013 09:45, Campbell Barton <ideasman42 at gmail.com> wrote:
>> >
>> > > 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
>> > > _______________________________________________
>> > > Bf-funboard mailing list
>> > > Bf-funboard at blender.org
>> > > http://lists.blender.org/mailman/listinfo/bf-funboard
>> > >
>> > _______________________________________________
>> > Bf-funboard mailing list
>> > Bf-funboard at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-funboard
>> >
>> _______________________________________________
>> Bf-funboard mailing list
>> Bf-funboard at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-funboard
>>
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard



-- 
- Campbell


More information about the Bf-funboard mailing list