[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: Srilakshmanan, Lakshman <Lakshman.Srilakshmanan_at_tradingpost.com.au>
Date: 2007-01-12 02:01:01 CET

Hi Ben,

Peanuts are good :)

The term trunk, tags & branches are only conventional, you can call them
what ever you want.
But, imagine if every one used a different name for the object we all
know as "car". Can you imagine the confusion.

Every time you asked for help in this mailing list and used the term
release_1, how would you expect anyone to know whether it is your trunk
or tag. If you are wondering why it should make a difference, please
understand that others are trying to conceptualise your problem without
having a good understanding of your implementation.

The reason we have conventions and standards is to avoid confusion and

Please find a link below which I found useful.


> -----Original Message-----
> From: B. Smith-Mannschott [mailto:benpsm@gmail.com]
> Sent: Friday, 12 January 2007 3:39 AM
> To: Subversion Users
> Subject: What's a "trunk" good for? (apart from eating peanuts)
> Hi!
> 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 messy.
> 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 tags.
> **
> 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
> reference)
> 20050912-i-made-this-up
> 20061031-some-text-about-what-i-did-here
> 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.
> Thanks,
> Ben
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 12 02:02:12 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.