Re: bzr repository ready?

[Karl Fogel]

"Stephen J. Turnbull" <address@hidden> writes:
> Karl Fogel writes:
>
>  > Everyone:
>  > 
>  > It's a wiki.  Please edit it :-).  
>
> OK, I've done so :-).  Please review my work, though; I'm far more
> expert on git and VCS theory than I am on bzr pragmatics.
>
> Specifically, one small change was I glossed the difference between
> the "dev" branch (one branch for sequences of small independent
> changes), vs. the SOME-TASKNAME branch (of which there will be many,
> each containing a set of related commits).  For example, typically you
> would delete a feature branch, but hang on to and reuse the "'dev"
> branch.
>
> The more important one is that AIUI, pushing directly from
> SOME-TASKNAME is a bad idea.  Typically, you want to merge that branch
> into trunk (the mirror branch), then commit (which automatically
> pushes to upstream in the recommended setup as a bound branch).

So just to make sure, when you wrote in the wiki

  "You can also just push it directly to the upstream master:
      bzr push bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk/"

you were talking about running that from within branch SOME-TASKNAME,
*not* from within the local trunk mirror, right?

(It might be good to always wrap commands in 'cd foo; ...; cd ..' so the
reader is absolutely clear on what's taking place where.)

Right below that, I tweaked the explanation a bit; please review and see
what you think.  There is one sentence that still puzzles me; it now
reads:

  "On the other hand, if you push directly from the ##SOME-TASKNAME##
   branch, your branch will be perceived as part of the mainline by
   ##bzr log##, while commits on the mainline (including merges from
   other developers and their detailed branch histories) will be hidden."

I don't understand the second part.  How will commits on the mainline be
hidden?  (That is, from whom will they be hidden, and in what situations?)

> The reason is that you want something like this, which is how Bazaar
> will present the merge and commit workflow:
>
> $ bzr log
> 3 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
> 2 Merge concurrent development
> 1 Parent of SOME-TASKNAME
> $ bzr log -n 0
> 3 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
>   3.3 Munge a bunch of fiddly little bits, all alike
>   3.2 Merge from trunk
>   3.1 Munge a fiddly little bunch of bits, all alike
> 2 Merge concurrent development
>   2.1 One big ol commit
> 1 Parent of SOME-TASKNAME
>   [several hundred thousand fiddly commits elided]
>
> Not this, which is how Bazaar will present the "just push" workflow:
>
> $ bzr log
> 5 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
> 4 Munge a bunch of fiddly little bits, all alike
> 3 Merge from trunk
> 2 Munge a fiddly little bunch of bits, all alike
> 1 Parent of SOME-TASKNAME
> $ bzr log -n 0
> 5 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME
> 4 Munge a bunch of fiddly little bits, all alike
> 3 Merge from trunk
>   3.1 Merge concurrent development
>     3.1.1 One big ol commit
> 2 Munge a fiddly little bunch of bits, all alike
> 1 Parent of SOME-TASKNAME
>   [several hundred thousand fiddly commits elided]
>
> Note how the latter inflates the importance of individual commits from
> SOME-TASKNAME, while confusing the timing with which various commits
> landed on the trunk.  (I'm not sure I got the above exactly right, but
> such effects are definitely part of the way bzr log looks at the
> branch's history.)

Agreed.

It might be better just to recommend the merge-and-commit workflow for
*everything*, always, and let those who want to become Bzr Jedi Masters
learn to do the "just push" on their own, when they are experienced
enough to understand the consequences.  Thoughts?

-Karl