[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: Byron Brummer <byron.brummer_at_livenation.com>
Date: 2007-01-11 22:54:15 CET

Outlook loves trashing plain text formatting to make messages as
unreadable as possible. Sorry, let me try this from Thunderbird:

Tim Hill <drtimhill@comcast.net> wrote:
> 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.

     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. Visually we're looking at
     something like:

                                _branch_bugfix_1.0 _branch_bugfix_2.0
                               / /
                              |_tag_rel_1.0 |_tag_rel_2.0
            \ ^\ ^\
             \_branch_rel_1.0_| \_branch_rel_2.0_____| |_branch_rel_3.0
                              | |
                              |_merge_point |_merge_point

     VS something like this:

     Branch_rel_1.0___|_now_is_bug_fixes_for_1.0 ->
                       \ _tag_rel_2.0
                        \_branch_rel_2.0___|_bugfix_2.0 ->
                                           \ _tag_rel_3.0

     In other words you effectively minimize major merging (aka
     integration) from the pattern by cascading the branches (you
     also eliminate seperate "bug fix" branches as the original
     branch just changes purpose after release). A history of "rel
     3.0" back to the beginning of time (crossing "branch points")
     gives a much more accurate history in a linear model then does
     a history of a "trunk". The reason being that you will see
     the actual history of the changes where they were actually
     made (on the branch), rather then the history of the merges of
     those changes (to the trunk). In practice integration merge
     commits tend to include much more then a single change set
     which means if you actually want the complete history of the
     changes you'll need to read the merge commit messages for
     clues (hopfully written up manually) as to what revisions on
     what branch the merge actually represents and then go fetch
     those histories seperately.

     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.


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