I found last summer’s Why Google Stores Billions of Lines of Code in a Single Repository (L) to be a much more interesting explanation of how this works out (it’s referenced by trunkbaseddevelopment.com, but the link there appears to be broken). Not only does it show that this is how Google prefers to work in this fashion, and explain some of their perceived benefits, but it also shows that it’s scalable to really big projects (or sets of projects, even, since Google apparently keeps all of theirs in one repository), something that I found quite surprising.
Personally, well, I don’t really have any personal experience with large projects at all, but I can’t help but think this would be problematic for the same reason that centralised systems like Subversion are (in my mind), since it appears to mimic the way Subversion etc was used… but then again, I never really used Subversion, so I’m a bit wary of my view being biased in favour of how DVCSes are typically used here.
Trunk-based development is a great approach, but…
This ensures the codebase is always releasable on demand and helps to make Continuous Delivery a reality.
…nothing leading up to that sentence describes anything to ensure a codebase is always releasable. That’s not something a branching model can provide, and the work required to do so is not substantially dependent on branching model. (On the other hand, it may be far easier or cheaper to do it when it can be focused on just one branch.)
Feels like yet another cult. Just like Gitflow stuff.
Educational material is better than cults because then you can make your own choices.
Suggest the vcs tag.
Also, this is funny in that it looks like people are reinventing the old model we used to use on Subversion. I’m not sure this is the big win they think it is.
The old subversion model was an excruciating experience, but this doesn’t sound quite the same – mainly because classic subversion made branching and merging so utterly painful that the short lived “feature branch reviewed and merged into master” style wasn’t commonly used.
As described here this is almost exactly ye olde standard github-using shop style. The site claims a difference (cutting a release off the post-merge trunk rather than the tip of feature-branch), but in my experience that’s the common approach anyways.
I may be just dense, but their attempt to describe how their approach is different from normal Gitflow doesn’t seem to clarify that much. :(
Also, their opening page seems to suggest to me that all development on the main trunk instead of in feature branches, which again seems weird.
This is as good of an idea of root folder based file system. Don’t use other folders just put everything in root.
Branches are really useful. If you are having an issue with them it’s because you’re using the tool wrong, not because it’s a bad tool. Throwing the tool out is not a good solution. If you cut yourself with a knife you don’t switch to only using spoons in the kitchen.
Trunk-based development doesn’t preclude using branches. That is specifically called out early on.
Depending on the team size, and the rate of commits, very short-lived feature/task branches are used for code-review and build checking (CI) to happen before commits land in the trunk for other developers to depend on.
It precludes real utilization of branches. The phrase “very short-lived” is key here. If you only used “very short lived” sub folders root based filesystem would still be just as stupid.
To me this “trunk based development” idea is a terrible solution to a real problem (poor use of branches) because the real solution (being intelligent about how you use branches) is more complicated than the bad solution (avoid using branches.)
Feature flags have all the problems of long-lived branches IME, and for the same reasons.