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

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

From: Brummer, Byron <ByronBrummer_at_LiveNation.com>
Date: 2007-01-11 21:57:50 CET

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
> 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
> the other is seen as a new branch. This kicks in when scanning
> in history toward a branch point. For example, you can tell Subversion
> display the log file back until a branch point is reached. This will
> 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
> "branch" of the tree that can be scanned all the way back to the start
> the repo without hitting any branch points. Some developers like this
> model since it provides a mental map that allows a more linear model
> historical analysis.

    Interesting. I'd argue that you'd hit merge points along the trunk
    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 ->

    In other words you effectively minimize major merging (aka
    from the pattern by cascading the branches (you also eliminate
    "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
    you will see the actual history of the changes where they were
    made (on the branch), rather then the history of the merges of those
    changes (to the trunk). In practice integration merge commits tend
    include much more then a single change set which means if you
    want the complete history of the changes you'll need to read the
    commit messages for clues (hopfully written up manually) as to what
    revisions on what branch the merge actually represents and then go
    those histories seperately.
    Thus the "linear history" idea of a trunk, IMHO, really is anything
    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 Thu Jan 11 22:47:07 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.