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:
>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 Fri Jan 12 05:29:30 2007