[Bf-committers] Wondering about the review of the command port patch...

Dietrich Bollmann diresu at web.de
Mon Sep 22 08:22:58 CEST 2008

Hi Toni :)

On Sun, 2008-09-21 at 10:23 +0300, Toni Alatalo wrote:
> well there was now the good news that people are starting to host a git 
> repo. anyone can do that. also if someone prefers/needs hg/mercurial or 
> bzr afaik they can just mirror one off the bf svn too. so do just use 
> e.g. the git repo to see how things go. there you can basically make 
> your own branch, from where people who want the feature in that branch 
> can pull that part of the code.

Do you have an url?

I need my command port functionality and will continue to work on it even after 
being rejected.  But as it is too much effort for me to write patches which 
I am not allowed to host on the blender patch tracker anyway I probably only 
would concentrate to make my own blender sources work without worrying about 
contributing patches anymore.

Looking at other blender versions which already exist, I fear that I am not
the only one choosing this approach...

So an official git repository where people like me could commit their work
would be something very nice - for the developers themselves as they would
not have to manage some private svn repository using something like the vendor 
drop method and for other people also who choose to patchwork their own 
blender version by unify different blender instances.

I - just as an example - use three different private branches:
- the command port branch, 
- a "multi-view" branch which allows to display and work on 
  several scenes in parallel and 
- a branch for manipulations of the python library for my private needs.  

Between all these probably the command port patch is the only one which is
useful for other people also.  

If there would be a distributed version control 
system I could make all of them a branch and unify them into another one which 
I could use to build my private blender.  In the same time other people could 
use my other branches (I do not have time to transform into patches) also if 
they are interested and continue to work on them creating some other private

> Dietrich Bollmann kirjoitti:
> >>      Sorry ... I initially wrote the command port for myself and
> >>      didn't intend to publish the code.  So some changes and
> >>     
> > Me myself!
> >   
> :p
> > frustration.  You are happy without it, I am happy using my own branch
> > and if there ever should be some other person who wants it he can apply
> >   
> i think there are people who want things like it, it is an interesting 
> effort - that's also why people care so much that all these posts about 
> it were written.

Arigatouuuu!!! - Thank you :)

...I put so much effort into it and was sooo unhappy about the
"official" reaction :(

I already sweared to myself to never work in an open source project
anymore (and reverted my decision after the worst emotions have been
slept over...).  And this after changing from Maya to Blender because of
rather wanting to write code for open source projects than for some
expensive closed source thing nobody can afford to buy anyway. (...I
relied on the Maya Command Port and decided to make it my first

So I am most grateful about your positive words :)

> in a way the feature you have made works also as setting requirements 
> for the 2.50 event system - the new architecture there should make 
> things like that easy to do, dunno if the mechnism will be some sort of 
> polling or what but anyway. oh seems that Stephen also already mentioned 
> later in these messages that talk he had with Ton about that on IRC the 
> other day.

...the polling is not part of my code - it is part of the current
implementation of the blender event loop I had to adapt my code to... 

See here:

> > ...Still, I like the idea of a second repository where everybody can
> > start his own branch to play around with.  There would be one official
> > branch using those things which the official developers agree on and
> > everybody else would be happy to work on his own version easily
> > upgradable to the latest trunk revision and to other persons additions
> > and without any need to get things accepted...
> >   
> well there was now the good news that people are starting to host a git 
> repo. anyone can do that. also if someone prefers/needs hg/mercurial or 
> bzr afaik they can just mirror one off the bf svn too. so do just use 
> e.g. the git repo to see how things go. there you can basically make 
> your own branch, from where people who want the feature in that branch 
> can pull that part of the code.
> i still wonder if using such distributed version control would also help 
> the company that was asking here for own branch. should be better than 
> forking a separate internal svn, 'cause svn can't track changes from 
> many places (i.e. the own internal repo stuff & BF). in other projects 
> (i'm mostly following ipython) distributed versioning systems seem to 
> help people on the personal level too, e.g. the technique of creating 
> branches for features while developing seems helpful .. to avoid the 
> problem of getting work on different issues mixed if you just have one 
> working copy (e.g. a svn checkout) and work on several things.

I read their posts - and immediately thought the same.  It is impossible
to work on some major functionality without being able to commit and
revert changes - which only some small group of developers is allowed to
in the case of blender.

I think it makes very much sense to have this "official" blender branch 
as it would be a mess if there wouldn't be some severe selection
criteria for new blender functionality.

But more personal needs should have their space also - and later might
be proved as something valuable and merged into the official blender
branch / trunk.

To not have such a possibility means to force people to work in their
private copy - which results in lots of interesting new ideas lost
on some private hard disk...

Also ... starting to feel like "nobody loves me" - :) - myself I
started to feel like people are rejecting my patches just because they
have been written by me.  As a person who somehow is able to also think
logically sometimes, I know that this probably is only part of my
private imagination.  But I also know that this part of my personality
is strong enough to stop me writing any more patches for blender...

So, if I could just work on experimental branches rather than begging
for acceptance of my patches, loosing all the time I spend to make my
changes another patch to be rejected over and over again, there would be
no possibility to develop this kind of emotions :)

> btw there used to be an experimental / wild tree of blender development 
> back in the cvs days even, the Tuhopuu (tree of destruction, a Finnish 
> name :) - but the burden of synching it got eventually to be too much 
> for the admins. but it was succesful for quite a long time in the sense 
> that many cool things got done and to use even (some artists used 
> tuhopuu for some things and regular blender for others).
> so having such unofficial / experimental Blenders has a good history 
> already, and hopefully the new tools make working on them more practical 
> and beneficial for the main line development too. interesting times, i'd 
> say, don't loose hope :) .. global open source dev is still a relatively 
> young activity and projects can learn.

...after my experiences with half of my patches rejected and messing
around with my "blender vendor drop" svn approach (which works well but
makes a lot of work when updating it to the current state of the blender
repository) I fully agree.  I wonder that there are still so many SVN
managed projects anyway...

Thank you again :)


> ~Toni
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list