Re: bzr workflow

[Stephen J. Turnbull]

Karl Fogel writes:

 > But at this point, I think we could update the BzrForEmacsDevs doc to
 > recommend just doing trivial mods in trunk and committing directly from
 > there.  Heck, that's what I'm doing with really simple stuff.
 > 
 > Can anyone think of any gotchas?  Particularly gotchas that would lead
 > to people on this list having to provide more support not less? :-)

No.  I just really dislike that workflow, personally.  (I accumulate
typo fixes and the like separately -- what's the rush? -- and don't
trust even the simplest code change to be correct without testing, at
least a compile, link, re-byte-compile, run test suite -- so my
quickfixes are batched, too.)  But that's a personal bias that I was
aware of, and I hope I mostly accounted for.

What consciously bothered me was experience with Mercurial.  In
Mercurial, commit-to-trunk leads to a very confusing DAG as myriads of
no-see-um branches get created, often in parallel, then very quickly
merged.  Unfortunately, they are very visible in the logs and in the
hgk DAG viewer (they're called "merge turds", which is quite apt), and
make use of hg diff confusing, too.

But in Bazaar with trunk bound to the public repo, that won't happen.
I didn't realize how powerful that technique would be.  I still don't
like it myself, but now I have convinced myself that it won't cause
any issues for other developers.  So I do not oppose including it
in BzrForEmacsDevs.