centralized workflow and tracking upstream questions

[Neil Martinsen-Burrell]

On Apr 5, 2008, at 1:04 AM, Tom Vaughan wrote:

> On Fri, Apr 4, 2008 at 7:06 PM, Neil Martinsen-Burrell <nmb at wartburg.edu 
> > wrote:
>> [snip]  I've found two
>> workarounds.  The first is to create the trunk by branching the  
>> vendor
>> location in the first place, e.g.
>
> Following the first suggestion, does this look right? I'm a little
> confused about why the trunk would have a log message that took place
> in the vendor branch, but I'm sure that's a bzr thing I don't
> understand yet. I can tell already I really like how bzr handles
> imports and merges...
[...]
> + bzr log trunk
> ------------------------------------------------------------
> revno: 3
> committer: Tom Vaughan <tom at software6.net>
> branch nick: trunk
> timestamp: Fri 2008-04-04 22:54:09 -0700
> message:
>  merged
>    ------------------------------------------------------------
>    revno: 1.1.1
>    committer: Tom Vaughan <tom at software6.net>
>    branch nick: vendor
>    timestamp: Fri 2008-04-04 22:54:09 -0700
>    message:
>      imported 2
> ------------------------------------------------------------
> revno: 2
> committer: Tom Vaughan <tom at software6.net>
> branch nick: trunk
> timestamp: Fri 2008-04-04 22:54:08 -0700
> message:
>  updates
> ------------------------------------------------------------
> revno: 1
> committer: Tom Vaughan <tom at software6.net>
> branch nick: vendor
> timestamp: Fri 2008-04-04 22:54:07 -0700
> message:
>  imported 1
> + ls trunk
> index.html
> + cat trunk/index.html
> <p>GOOD BYE WORLD!</p>

That looks exactly right.  The log messages from the vendor branch  
that appear in the trunk are due to the fact that a merge in bzr  
actually brings in revisions that existed in the other branches.  Note  
the indented revision labeled revno: 1.1.1.  The indentation and  
dotted revision number imply that revision came from a different  
branch.  The bringing in of revisions from branches that are merged is  
one reason why shared repositories make sense.  The revision labeled  
1.1.1 here is the same revision as that labeled 2 in the vendor  
branch.  The effifiency of a shared repository comes from storing this  
revision only once.  A good visual representation of this is possible  
busing the bzr-gtk plugin and the ``bzr viz`` command.

-Neil