[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:
>snip<
> 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
    Trunk____________________|______________________|______________--->
           \ ^\ ^\
            \_branch_rel_1.0_| \_branch_rel_2.0_____| |_branch_rel_3.0
                             | |
                             |_merge_point |_merge_point

    VS something like this:
    
                     _tag_rel_1.0
    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
 
\_branch_rel_3.0___|_bugfix_3.0
                                                              \
 
\_branch_rel_4.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.

-Byron

---------------------------------------------------------------------
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.