[LLVMdev] Develop on trunk.

Chandler Carruth chandlerc at google.com
Wed Jun 13 11:59:05 PDT 2012


On Wed, Jun 13, 2012 at 11:43 AM, Andrew Trick <atrick at apple.com> wrote:

>
> On Jun 13, 2012, at 7:15 AM, Sergei Larin <slarin at codeaurora.org> wrote:
>
> Again, this is branch code, but if I can see something wrong in platform
> independent portion, I'll track it on the trunk.
>
>
> I hate to be the one to start this thread, but I have to say it at least
> once...
>
> General advice. Working off trunk will be less painful than cherry-picking.
>

TL;DR: Here here. Yes, more, please!

<soap box>
I'll go further: don't use development branches. It's just not worth it.

I say this as someone who created a development branch of Clang. It was and
is a pile of pain. We want to kill it with fire.

A lot of people think that a development branch is a useful way to solve
problems they run into while developing on trunk:
- Commit velocity
- Code review latency
- API instability
- Rough or WIP code being seen by others

I assert that these are either not actual problems when working on trunk,
or are problems that will actually be worse with a development branch. They
are very bad reasons to form one.
- Commit velocity may go up, but testing, correctness, and quality of those
commits will go down. You also have the added burden of having to commit
merges.
- Code review latency doesn't go away, it gets deferred until the time at
which you want to re-integrate your changes. Deferring code review is like
deferring payments on a loan. The more you do it, and the longer you do it,
the more interest you build up. It's especially like a loan in that it is a
*compounding* phenomenon. However, it's worse than most loans, because the
interest rate is somewhere between 20% and 2000%. In such scenarios,
micro-payments start to make sense, in the same way that tiny incremental
patches make sense on trunk.
- API instability is the exact same problem as code review latency -- the
API is no more stable, you're just deferring work. The interest rate here
is much lower at least, but there is a secondary gotcha -- if your code is
on trunk, then the API *changer* will do much of the work for you.
- Rough / WIP code *should* be seen by others, in order to get early
feedback, avoid bad paths of implementation etc. We should indoctrinate
ourselves as developers with a delightful glee in showing code before it's
100% ready for prime time.


There are actual cases where you must use a development branch, such as due
to controversial changes that need to be demonstrated as viable before
accepted, or drastic internal changes that require a lot of work to get
into a working state (the type-system rewrite of LLVM is a good example
here).

If you find yourself in such a scenario, it is essential to make the
development branch look as much like trunk as possible. Integrate daily at
least, and multiple times a day if you can. Otherwise, all of the problems
above will eat away at your productivity.

</soap box>

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120613/4c6ada4b/attachment.html>


More information about the llvm-dev mailing list