On 1/11/07, Ben Smith-Mannschott wrote:
> We do all of our development work in the various "trunk" of
> our repository here, but really, it might as well just be a
> branch called "release-1", since that's what we're working
> toward and we all know that. When we're ready to stabilize
> "release-1", we could branch it by copying it to "release-2"
> where bleeding-edge development would continue while
> stabilization fixes are made to "release-1".
> What's so special about "trunk"? In retrospect, wouldn't it be
> clearer just to work "trunkless"?
Tim Hill <firstname.lastname@example.org> wrote:
> [...] A branch is not a truly symmetrical operation. That is,
> it's not a true "fork", where both outgoing halves are
> equivalent. Instead, from a historical perspective, one half
> (the "trunk") is seen as unchanged while the other is seen as
> a new branch. This kicks in when scanning backwards in history
> toward a branch point. [...]
> [...] In this sense, the trunk is special in that it is the
> only "branch" of the tree that can be scanned all the way back
> to the start of the repo without hitting any branch
> points. Some developers like this model since it provides a
> mental map that allows a more linear model for historical
On 1/11/07, Byron Brummer <email@example.com> wrote:
> Interesting. I'd argue that you'd hit merge points along the
> trunk line which are at least as significant as branch points.
> Furthermore fetching the real history could be much harder as
> the merge likely represents much more history then was
> included in the merge commit. [...]
> Thus the "linear history" idea of a trunk, IMHO, really is
> anything but. A branch-only pattern, ironically, results in
> the ability to query for a much more linear history.
Your illustration of the logical consequences of working
'trunkless' brought me an "aha!". I guess that's where I was
going with my first example, but in my usual muddle I couldn't
see it clearly.
You're diagram illustrates that it's a good way of modeling
software that has multiple releases and a maintenance
lifecycle. Would you mind if I incorporated your insight into my
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jan 12 10:36:49 2007