[Bf-committers] Roadmap for 2.5x - 2.6x - beyond

[Lars Krueger]

-------- Original-Nachricht --------
> Datum: Sat, 19 Mar 2011 13:34:29 -0500
> Von: Reuben Martin <reuben.m at gmail.com>
> An: bf-blender developers <bf-committers at blender.org>
> Betreff: Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond

> I don't know if this has already been discussed or not, but has
> anybody looked into moving to a git based system? From what I
> understand, it makes it much easier for developers to track and keep
> their development branches in sync with the tip of the main
> development trunk. It seems that often the development branches get
> way out of sync with trunk, and then that often becomes a major
> obstacle to merging them. Git seems to make the managing of branches a
> much more trivial operation.

About a year ago our department switched to git. We replaced a mix of CVS/SVN repos with git, but only for new projects. Our setup uses a centralized repo with ssh access from Windows and Linux machines.

My experiences so far:

Pros:
- Branch management is where git shines. Making a new branch is just one click and entering a name. 
- The distributed repo idea is ideal if you have some machines that are off-line frequently. Workflow: Server -> USB stick -> off-line machine, develop there, push back to stick, then to server. Probably not relevant here.
- It's nice to be able to apply commits out of sequence and across branches.
- You can integrate version management and release management into one operation.
- Comes with a decent gui. 99% of the daily work doesn't require a command line.
- It just works. Even if you mess up a commit, you can always fix it.

Cons:
- submodules are hard to get right and depend on your workflow, account setup, and supermodule setup.

Neutral:
- Git does not alleviate developers from talking to each other. If two people change the same line in different ways, git will mark it as a conflict.

> I would present several hurdles though. Time require to move from svn,

There is an import program for CVS and one for SVN. We tried the CVS import and it worked.

> completely different code management paradigm, and possible issues for

This mostly depends on the community. git is just a mechanism, in contrast to SVN/CVS which also impose a certain policy.

We use the same commit-right-for-all approach with central server that we use with CVS/SVN. It is also possible to allow a workflow where everybody can checkout, but only a few can commit.

> windows developers. (Not sure if that last one is still an issue any
> more...)

Nope. Works. I use it under Windows 7 at home and XP at work. Both work with the GUI and the CLI. I recommend to remove the translation files to better understand the English docs on the web.

I only have experiences with ssh:// transfer, not sure about git:// transfers.

> But from observing other projects, it does seem to lend some real
> advantages to a quick development cycle with many development
> branches.

It requires a certain discipline. If you only have one repo with write access for everybody, I recommend one branch per user that serves as a personal sandbox. From that, users can branch off at will. In addition to that, a branch for the latest stable release and a branch for the current offical development release.

My suggestion is to setup the repo in a similar way to SVN:

1. Everybody can pull (checkout in SVN terms), but only approved developers can push (SVN speak: commit). Use one git repo for everybody. That way, you can easily merge other peoples branches into your sandbox-branch.

2. Every user has a working branch of the name <account>_work. From that, fork branches off at will. Use the master branch for the latest developer version, add a branch for stable releases and put bug fixes there. Merge the bug fixes into the developer version. This way you can separate bug fixes from new features.

3. Each new feature gets a separate branch. This can be as small as a new button in a single python file or as big as a new game engine. Bundle the branch and put it on the patch tracker. The module manager can download the bundle like the SVN patches. The bundle merges into the repo by adding the branch. From there, you can clean up the code and finally merge with the development branch.

I recommend the following sites:
progit.org
http://osteele.com/archives/2008/05/my-git-workflow (and links)

This workflow might be appropriate for blender (looks most like current SVN workflow, I guess)
http://nvie.com/posts/a-successful-git-branching-model/

-- 
Dr. Lars Krueger


GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl