[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: What's a "trunk" good for? (apart from eating peanuts)

From: B. Smith-Mannschott <benpsm_at_gmail.com>
Date: 2007-01-12 10:36:31 CET

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 <drtimhill@comcast.net> 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
> analysis.

On 1/11/07, Byron Brummer <byron.brummer@livenation.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

// ben

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 12 10:36:49 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.