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