The names "trunk", "branches" etc are conventional only; you are free
to use others and I, in fact, frequently use "main" instead of
"trunk" (I got used to this years ago). However, some Subversion
clients, such as Tortoise, understand the "tags" name as special. For
example, Tortoise SVN will warn if you attempt to alter anything in a
path that includes "tags".
You are correct in that "trunk" carries no special significance to
the tool, and your example of the "blearly" trunk thats never quite a
release is correct. However, there is one aspect where this is
significant: 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. For
example, you can tell Subversion to display the log file back until a
branch point is reached. This will work on the branch half, but not
the trunk half (since they are not symmetrical). 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 Jan 11, 2007, at 8:54 AM, <Chris.Fouts@qimonda.com>
>> -----Original Message-----
>> From: B. Smith-Mannschott [mailto:email@example.com]
>> Sent: Thursday, January 11, 2007 11:39 AM
>> To: Subversion Users
>> Subject: What's a "trunk" good for? (apart from eating peanuts)
>> I'm muddling along trying to develop part of a little internal
>> subversion crash course at my place of work. Currently, I'm
>> trying to teach the concepts of trunk, branch and tag. The
>> more I think about it, the more I'm convinced that 'trunk' is
>> conceptual baggage we've schlepped in from the world of CVS.
>> Trunk is just a special case of branch. The "everything is a
>> directory" reality of subversion just makes this even more obvious.
>> I guess my conceptual problem is two-fold:
>> (1) it's meaning: why should it get special treatment?
>> (2) it's appellation: why should we call it "trunk"?
>> Conventionally, I think "trunk" used for the 'main line of
>> development'. At least that's what we've been doing. But what
>> does that really mean?
>> 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".
>> In this scenario it's seems like it's an eternally shambling
>> branch forever doomed to blearily stumble from one release to
>> the next, never quite sure which it belongs to. In a word, it's
>> What's so special about "trunk"? In retrospect, wouldn't it
>> be clearer just to work "trunkless"?
>> In another very different case, I have a small internal web
>> site (publishing a collection of XML schemas), where 'trunk' is the
>> *stable* (the website is a published version of the content.
>> I use short-lived feature branches to make changes and then
>> merge these back into trunk. But in this case there is only
>> ever *one* true version of the site so there's no need to keep
>> parallel branches of development open. (Though that may
>> change, and then what?)
>> But even here, where "trunk" is useful it's clear that it's
>> just another branch. Heck, I could even give it a marginally
>> more sensible name, like "branches/official-version" or whatever.
>> In a third case, we're managing the publication of a
>> collection of documentation for our system. Here we've left
>> the trunk/branch/tag naming convention behind entirely, also
>> in part because it's used by non-technical users.
>> "Work" holds the version currently under active modification.
>> That is, it's the staging area for the next publication.
>> "Final" contains copies of Work. These are essentially
>> release branches. They are made in order to have a stable
>> collection of source documents (MS Word) from which to produce
>> what's actually delivered (PDF).
>> "Published" contains copies of "Final" branches recording what
>> was included in any given published version. These correspond to
>> In a fourth case, I've created a small repository for a
>> decidedly non- technical user whose previous version control
>> consisted of making renamed copies of the files she maintained
>> *before* she modified them. She was blessedly consistent in
>> that the renaming always consisted of adding an ISO date to
>> the original name of the file.
>> Out of this motley collection, I created a repository
>> consisting of a single active branch (trunk) and a plethora of
>> tags. But, I didn't call them that. Instead I localized them
>> to the native language of my workplace:
>> aktuell/ ("current", i.e. the "trunk")
>> archiv/ ("archive" -- a place to keep old copies of things for
>> readme/ (user documentation)
>> She uses tortoiseSVN and I've shown her how to make changes to
>> "aktuell" and commit them and then how to copy-and-rename "Aktuell"
>> to a new subdirectory in "archiv" using tortoiseSVN's
>> hand-but- unintuitive right-mouse-button-drag maneuver.
>> It seems to work for her, but it sure isn't very conventional.
>> I guess my difficulty is that I'm trying to give guidance. But
>> I know that it's all just *convention* so the most honest
>> guidance I could give is: "actually you can do what you want,
>> but **you've got to understand what you're doing!**". Which
>> begs the question: do I truly understand what *I'm* doing?
>> I'd be curious as to how you are using (or not using) "trunk"
>> and in particular what *meaning* you've given it.
>> To unsubscribe, e-mail: firstname.lastname@example.org
>> For additional commands, e-mail: email@example.com
> To unsubscribe, e-mail: firstname.lastname@example.org
> For additional commands, e-mail: email@example.com
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jan 11 20:33:41 2007