centralized workflow and tracking upstream questions

Tom Vaughan tom at software6.net
Mon Apr 7 05:32:55 BST 2008


On Sat, Apr 5, 2008 at 10:10 AM, Neil Martinsen-Burrell
<nmb at wartburg.edu> wrote:
> 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
>

Many thanks Neil and to everyone who help with this.

-Tom



More information about the bazaar mailing list