[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: Tim Hill <drtimhill_at_comcast.net>
Date: 2007-01-12 00:12:45 CET

Yes, I pretty much agree with you -- I wasn't really defending the
"trunk" model, just noting how its viewed by Subversion. In fact, the
lack of good merge tracking is currently a weak point in svn, though
I understand that is being worked on.

--Tim

On Jan 11, 2007, at 12:57 PM, Brummer, Byron wrote:

>
> 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 00:13:02 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.