On Wed, Jun 06, 2007 at 08:40:52AM -0400, David Abrahams wrote:
I've been asking myself why we're still talking about a "trunk," too. Can somebody explain why, and what it's supposed to mean?
Heh, nobody bit on this one. I'm feeling brave, I'll give it a try. 'trunk', as we CVS users typically understand, is data. It's where you commit if you're a developer. It's a single branch in a single repository. If you want the latest stuff, you check out the 'trunk'. But this sense of 'trunk' also implies the typical CVS development process: everyone synchronizes their work to that one branch, and when that is stable, a branch is made for release; great effort is made to keep all development on one copy of the source tree, as branching/merging is typically difficult and expensive; etc. Since CVS is made to support development in a particular way, that way is fundamental to our understanding of 'trunk'. So to talk about the 'trunk' in a CVS-less environment is to either be vague or to imply that the development process is CVS like. You're talking about a location, and given is that the tools will dictate workflow (it's the trunk, of course, everybody knows what the trunk is for, there's no other way to do things)... but in the absence of CVS that isn't the case. You're leaving the workflow undefined. I thought about this question as I rewatched the talk this morning: Linus is extolling the virtues of being distributed and outlines a scenario, the release process, wherein the development group is happily developing along on their branch. The verification group is pulling down code (that is, merging code into their branch) from the development group's branch as they like, tweaking a bit, doing their thing. The testing group, similarly, pulls down (merges) code from the verification group, tests, and gets releases out the door. As he describes it, all three groups are working, all the time. Upstream groups are for the most part blissfully unaware of what is happening later in the pipeline, except, presumably, to the extent that they get interrupted to assist with particularly nasty bugs or whatever. (You could imagine a need to merge code backwards up the pipeline if the code that the development group was producing diverged enough from the testing group's code that merging stopped working.) There is a constant flow of code through this pipeline; predominantly, but not exclusively, in one direction. So, where's the trunk? Do all of these branches represent one composite trunk? The testing group may have patches that the development group never knows about, as testing is always merging changes in to what they've already released. So you could say that there is no 'trunk' in the scenario above... Perhaps there are many, all along this pipeline, a composite 'trunk', many locations in many repositories. But that's not the whole story since those repositories are useless without the pipeline behavior that makes them 'trunk'. Think separation of data structures and algorithms. Trunk is a process *and* the data that it operates on. There are many varieties, and we tend to imply the CVS kind. I notice some paralllel between the devel-verification-testing pipeline that Torvalds describes and the proposed stable-devel boost pipeline. The abolishment of 'trunk' in favor of these other terms might make good sense; at least the terminology won't excite incorrect assumptions about the process. There. I gave it a shot. -t