bzr workflow

bzr workflow

[Sam Steingold]

http://www.emacswiki.org/emacs/BzrForEmacsDevs
appears to indicate that I need to commit _twice_ for each change (with the
same log message?):

Workflow for a Quick Change
...
bzr commit -m "Fix bla bla bla (closes Bug #1)."

Merging Into the Upstream Master
...
bzr merge
bzr commit -m "Merge: fix bla bla bla (closes Bug #1)."


1. Am I the only one who thinks this is a little too convoluted? (the only
other DVC I regularly use is hg, and there the workflow is "commit+push"
instead of the recommended emacs workflow "commit+merge+commit").

2. Is there a way to emacs-automate this? I.e., the first commit is easily done
from under emacs using the vc-dir buffer: mark the files, hit C-x v v to the to
the commit message buffer, then C-c C-a will insert the ChangeLog text and C-c
C-c will commit. Then I have to switch to a bash window, go to trunk, then
merge, and the then commit - but then I need either a second vc-dir buffer in
emacs, or I need to do that (a multi-line commit message!) from the shell.
There must be a better way to do that!

thanks.

Re: bzr workflow

[Andreas Schwab]

Sam Steingold <sds@gnu.org> writes:

> 1. Am I the only one who thinks this is a little too convoluted? (the only
> other DVC I regularly use is hg, and there the workflow is "commit+push"
> instead of the recommended emacs workflow "commit+merge+commit").

Nothing stops you from using the more advanced workflow.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bzr workflow

[Óscar Fuentes]

Sam Steingold <sds@gnu.org> writes:

> http://www.emacswiki.org/emacs/BzrForEmacsDevs
> appears to indicate that I need to commit _twice_ for each change (with the
> same log message?):

This was extensively discussed here a few days ago.

> Workflow for a Quick Change
> ...
> bzr commit -m "Fix bla bla bla (closes Bug #1)."
>
> Merging Into the Upstream Master
> ...
> bzr merge
> bzr commit -m "Merge: fix bla bla bla (closes Bug #1)."
>
>
> 1. Am I the only one who thinks this is a little too convoluted?

No, you are not alone.

You can use

http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs

or a variation of it as described below.

There is something that I disagree with BzrForEmacsDevs: a quickfix that
requires more than one commit or that spans so long in time to warrant a
merge from upstream does not qualify as a quickfix for me.

For the people that works with the distributed workflow and thinks that
a quickfix should map to one and only one commit, there is an easy
solution: bind your quickfixes/ branch to upstream:

cd quickfixes/
bzr bind URL_TO_UPSTREAM/trunk

after this, your workflow for quick fixes becomes:

bzr up
bzr commit -m "Fix bla bla bla (closes Bug #1)."

and you can use VC-dir all along.

[snip]

-- 
Óscar

Re: bzr workflow

[Sam Steingold]

On 1/11/10, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Sam Steingold <sds@gnu.org> writes:
>
>  > 1. Am I the only one who thinks this is a little too convoluted? (the only
>  > other DVC I regularly use is hg, and there the workflow is "commit+push"
>  > instead of the recommended emacs workflow "commit+merge+commit").
>
>
> Nothing stops you from using the more advanced workflow.

what "more advanced workflow"?

http://www.emacswiki.org/emacs/BzrForEmacsDevs

It might occur to you to save some effort by just doing bzr push
directly to the upstream master from inside the quickfixes branch:

      cd $DEVHOME/emacs/quickfixes
      bzr push sftp://USERNAME@bzr.savannah.gnu.org/srv/bzr/emacs/trunk/

Do not do this — it can cause history to be displayed in a strange way
in the upstream master, any mirrors or branches of it, and your own
branch later. Search for the word “hidden” in this mail for more
details.

-- 
Sam Steingold <http://sds.podval.org>

Re: bzr workflow

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Mon, 11 Jan 2010 16:10:03 -0500
> 
> http://www.emacswiki.org/emacs/BzrForEmacsDevs
> appears to indicate that I need to commit _twice_ for each change (with the
> same log message?):
> 
> Workflow for a Quick Change
> ...
> bzr commit -m "Fix bla bla bla (closes Bug #1)."
> 
> Merging Into the Upstream Master
> ...
> bzr merge
> bzr commit -m "Merge: fix bla bla bla (closes Bug #1)."

It's not twice, it's n+1, where n is the number of commits you do on
the quickfixes branch while you work on the change, and the +1 is to
merge with upstream before you send the changes to the remote
repository on Savannah.  For serious development, you will want that,
and you cannot avoid the last merge with upstream, of course, for
obvious reasons.

As others told you, if your "quick fix" is just a simple change, it
doesn't need a separate branch.  FWIW, I make such changes directly in
the trunk tree, and then the workflow looks very similar to CVS: just
hack, test, and commit once, which commits to the remote repository as
well as the local one.

Re: bzr workflow

[Chong Yidong]

Óscar Fuentes <ofv@wanadoo.es> writes:

> No, you are not alone.
>
> You can use
>
> http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs
>
> or a variation of it as described below.
>
> There is something that I disagree with BzrForEmacsDevs: a quickfix that
> requires more than one commit or that spans so long in time to warrant a
> merge from upstream does not qualify as a quickfix for me.

Agree.  I've edited the language in the two documents so that they do
not recommend one workflow over another.  The ability to use VC-dir is
important.

Re: bzr workflow

[Andreas Schwab]

Sam Steingold <sds@gnu.org> writes:

> On 1/11/10, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Sam Steingold <sds@gnu.org> writes:
>>
>>  > 1. Am I the only one who thinks this is a little too convoluted? (the only
>>  > other DVC I regularly use is hg, and there the workflow is "commit+push"
>>  > instead of the recommended emacs workflow "commit+merge+commit").
>>
>>
>> Nothing stops you from using the more advanced workflow.
>
> what "more advanced workflow"?

The one you are used to.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bzr workflow

[Jan Djärv]

Óscar Fuentes skrev:

> 
> There is something that I disagree with BzrForEmacsDevs: a quickfix that
> requires more than one commit or that spans so long in time to warrant a
> merge from upstream does not qualify as a quickfix for me.
>

This is too simple.  There have been many times in the CVS days when I tried 
to commit a change only to find out there was a conflict (usually ChangeLog). 
  So I always merge from upstream before committing to upstream.  So what you 
are saying is in fact, there are no quick fixes.

What starts out as a (presumed) quickfix often turns in to a week/month long 
fix.  To assume that one can always beforehand descide if one is about to do a 
quickfix or not is also too simple minded.

Bzr feels very strange and uncomfortable.  It is workable, but not smooth or 
elegant, just kind of icky.

	Jan D.

Re: bzr workflow

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Óscar Fuentes skrev:
>
>>
>> There is something that I disagree with BzrForEmacsDevs: a quickfix that
>> requires more than one commit or that spans so long in time to warrant a
>> merge from upstream does not qualify as a quickfix for me.
>>
>
> This is too simple.  There have been many times in the CVS days when I
> tried to commit a change only to find out there was a conflict
> (usually ChangeLog). So I always merge from upstream before committing
> to upstream.

That's what `bzr up' does on a bound branch or checkout.

> So what you are saying is in fact, there are no quick fixes.
>
> What starts out as a (presumed) quickfix often turns in to a
> week/month long fix.  To assume that one can always beforehand descide
> if one is about to do a quickfix or not is also too simple minded.

You can easily turn your quickfixes/ branch into something else:

cd quickfixes/
bzr unbind   # Make this a regular branch
cd ..
mv quickfixes/ complex-fix-for-bug342
bzr branch trunk/ quickfixes  # Recreate quickfixes/ branch
cd quickfixes/
bzr bind URL_TO_UPSTREAM/trunk

There are methods for translating the uncommitted changes from one
branch to another too, if you prefer to not having to recreate the
quickfixes/ branch:

bzr branch trunk/ complex-fix-for-bug342
cd complex-fix-for-bug342
bzr merge --uncommitted ../quickfixes
cd ../quickfixes
bzr revert

> Bzr feels very strange and uncomfortable.  It is workable, but not
> smooth or elegant, just kind of icky.

IMO, for the case we are talking about, it works nicely.

-- 
Óscar

Re: bzr workflow

[Jan Djärv]

Óscar Fuentes skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Óscar Fuentes skrev:
>>
>>> There is something that I disagree with BzrForEmacsDevs: a quickfix that
>>> requires more than one commit or that spans so long in time to warrant a
>>> merge from upstream does not qualify as a quickfix for me.
>>>
>> This is too simple.  There have been many times in the CVS days when I
>> tried to commit a change only to find out there was a conflict
>> (usually ChangeLog). So I always merge from upstream before committing
>> to upstream.
> 
> That's what `bzr up' does on a bound branch or checkout.

Yes, but that is not in the quickfix branch.  You must resolve and test 
conflicts in the qucik fix branch.  This can't be done in the trunk branch (as 
per the Wiki) as we don't even compile there.  You could just resolve 
conflicts textually, but not testing it before comitting upstream is noting I 
would do.

>>
>> What starts out as a (presumed) quickfix often turns in to a
>> week/month long fix.  To assume that one can always beforehand descide
>> if one is about to do a quickfix or not is also too simple minded.
> 
> You can easily turn your quickfixes/ branch into something else:
> 
> cd quickfixes/
> bzr unbind   # Make this a regular branch
> cd ..
> mv quickfixes/ complex-fix-for-bug342
> bzr branch trunk/ quickfixes  # Recreate quickfixes/ branch
> cd quickfixes/
> bzr bind URL_TO_UPSTREAM/trunk

I wouldn't call that easy, but thanks for the info.
This is not how the Wiki says the quick fix branch should be created though, 
the last bind isn't there.

> 
> There are methods for translating the uncommitted changes from one
> branch to another too, if you prefer to not having to recreate the
> quickfixes/ branch:
> 
> bzr branch trunk/ complex-fix-for-bug342
> cd complex-fix-for-bug342
> bzr merge --uncommitted ../quickfixes
> cd ../quickfixes
> bzr revert
> 

It doesn't matter which way you do it, you still have to do make bootstrap 
again, and that is where time goes.

>> Bzr feels very strange and uncomfortable.  It is workable, but not
>> smooth or elegant, just kind of icky.
> 
> IMO, for the case we are talking about, it works nicely.
> 

On some definition of "nicely", sure.

	Jan D.

Re: bzr workflow

[Óscar Fuentes]

Jan Djärv <jan.h.d@swipnet.se> writes:

> This is not how the Wiki says the quick fix branch should be created
> though, the last bind isn't there.

This subthread is not about the recommendations on the Wiki. It's about
an alternative to them specific for to the quickfixes/ case.

[snip]

-- 
Óscar

Re: bzr workflow

[Eli Zaretskii]

> Date: Tue, 12 Jan 2010 08:47:02 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: emacs-devel@gnu.org
> 
> To assume that one can always beforehand descide if one is about to do a 
> quickfix or not is also too simple minded.

You don't need to decide in advance.  Start in the trunk or in
quickfix, and if you later see that a separate branch is required,
then

   bzr branch trunk fix-something
   cd fix-something
   bzr merge ../trunk --uncommitted
   cd ../trunk
   bzr revert
   cd ../fix-something
   [and hack in the `fix-something' branch]

This copies uncommitted changes from trunk to a newly created branch,
then reverts the trunk to its previous pristine state, before you
started your not-so-simple fix.

Re: bzr workflow

[Eli Zaretskii]

> Date: Tue, 12 Jan 2010 10:39:44 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: emacs-devel@gnu.org
> 
> you still have to do make bootstrap again, and that is where time
> goes.

??? On what OS?  It takes about 20 minutes on MS-Windows (which is
indeed painful), but on GNU/Linux I'm done in 5.

Of course, that's not to say that one should bootstrap every hour, but
if you need to do it every now and then, when you decide that another
branch is in order...

Furthermore, there are Bazaar tricks to have co-located branches, in
which case you don't need to bootstrap at all.

Re: bzr workflow

[Juanma Barranquero]

On Tue, Jan 12, 2010 at 10:39, Jan Djärv <jan.h.d@swipnet.se> wrote:

> This can't be done in the trunk branch
> (as per the Wiki) as we don't even compile there.

FWIW, there's no intrinsic problem in building trunk; that it is not
recommended in the introductory document just means that it is added
complexity not deemed necessary for beginners, but of course you can
do it if you know what you're doing...

That said, as Eli has commented, bootstrapping is generally not *that*
painful, and you can use the checkout/switch method that Óscar
explained a while ago to have (sort of) colocated branches and avoid
most bootstrappings.

    Juanma

Re: bzr workflow

[Juanma Barranquero]

On Wed, Jan 13, 2010 at 03:18, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> But this isn't about "general", it's about a workflow where "bzr
> merge" is considered too painful.

Not bzr merge, but make bootstrap (so, in fact, is "bzr branch trunk
taskbranch" which is considered painful). And some of the alternatives
to having to bootstrap every branch have been already discussed.

    Juanma

Re: bzr workflow

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Tue, Jan 12, 2010 at 10:39, Jan Djärv <jan.h.d@swipnet.se> wrote:
 > 
 > > This can't be done in the trunk branch
 > > (as per the Wiki) as we don't even compile there.
 > 
 > FWIW, there's no intrinsic problem in building trunk; that it is not
 > recommended in the introductory document just means that it is added
 > complexity not deemed necessary for beginners,

As far as I know, it's not complex one way or the other, although I
have been a vpath addict for over a decade, so I have no experience.
The only thing you need to be careful about is that *all* build
products are in .bzrignore, and that you don't accidentally add any
scratch files you personally create, since the recommended workflows
do most pushing from there.

FWIW, the real reason that we didn't say anything about it is that the
original idea was that the trunk would be treeless, but it turns out
that you can't merge a branch without a tree.  (It's not impossible in
theory -- eg, if the divergent changes affect different files -- but
bzr won't do it.)

 > That said, as Eli has commented, bootstrapping is generally not *that*
 > painful,

But this isn't about "general", it's about a workflow where "bzr
merge" is considered too painful.

Re: bzr workflow

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>FWIW, the real reason that we didn't say anything about it is that the
>original idea was that the trunk would be treeless, but it turns out
>that you can't merge a branch without a tree.  (It's not impossible in
>theory -- eg, if the divergent changes affect different files -- but
>bzr won't do it.)

I think it was that, and a desire not to throw too many different ways
of doing things at newbies.

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? :-)

Re: bzr workflow

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Wed, Jan 13, 2010 at 03:18, Stephen J. Turnbull <stephen@xemacs.org> wrote:
 > 
 > > But this isn't about "general", it's about a workflow where "bzr
 > > merge" is considered too painful.
 > 
 > Not bzr merge, but make bootstrap

No, I really meant "bzr merge".  AIUI people were discussing the
quickfixes branch, not feature branches.  The claim has been that
spending 15 seconds (in most cases) making a trivial merge to trunk
before pushing is too annoying.  If that's unacceptable, even five
minutes spent on an unnecessary bootstrap clearly would be too.

(Aside: the emphasis in recent threads on the importance of
streamlining the quickfixes workflow scares me.)

Re: bzr workflow

[Lennart Borgman]

On Wed, Jan 13, 2010 at 4:23 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Juanma Barranquero writes:
>  > On Wed, Jan 13, 2010 at 03:18, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>  >
>  > > But this isn't about "general", it's about a workflow where "bzr
>  > > merge" is considered too painful.
>  >
>  > Not bzr merge, but make bootstrap
>
> No, I really meant "bzr merge".  AIUI people were discussing the
> quickfixes branch, not feature branches.  The claim has been that
> spending 15 seconds (in most cases) making a trivial merge to trunk
> before pushing is too annoying.  If that's unacceptable, even five
> minutes spent on an unnecessary bootstrap clearly would be too.
>
> (Aside: the emphasis in recent threads on the importance of
> streamlining the quickfixes workflow scares me.)


It would be very good if someone pointed out on the wiki page where
(and perhaps how) you build Emacs. Do you do that in the trunk
directory, or? Is there anything special to consider?

Re: bzr workflow

[Juanma Barranquero]

On Wed, Jan 13, 2010 at 04:23, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> No, I really meant "bzr merge".  AIUI people were discussing the
> quickfixes branch, not feature branches.  The claim has been that
> spending 15 seconds (in most cases) making a trivial merge to trunk
> before pushing is too annoying.

Well, what I was answering was the comment that having to bootstrap was onerous.

> (Aside: the emphasis in recent threads on the importance of
> streamlining the quickfixes workflow scares me.)

Me too, because I think it leads to everything done on trunk.

    Juanma

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.

Re: bzr workflow

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Tue, 12 Jan 2010 21:27:42 -0500
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
> 	Juanma Barranquero <lekktu@gmail.com>,
> 	Jan Djärv <jan.h.d@swipnet.se>, emacs-devel@gnu.org
> 
> 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?

If there are any gotchas, I have yet to see them.  I've been doing
this since day one.

Re: bzr workflow

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Wed, 13 Jan 2010 04:29:51 +0100
> 
> It would be very good if someone pointed out on the wiki page where
> (and perhaps how) you build Emacs. Do you do that in the trunk
> directory

Yes.

> Is there anything special to consider?

No.  Just do it as usual.

Re: bzr workflow

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 13 Jan 2010 13:02:37 +0900
> 
> 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.

Testing before committing is (or should be) good practice, not just
personal bias.  I always at least rebuild Emacs, even if it's just a
typo in a comment, before committing.  I was doing that with CVS as
well.  There's nothing more embarrassing than botching the build by
committing untested changes.

> 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.

Yes, I think we should do that.  I'm doing all my quick-fixing stuff
in the trunk directly.

Re: bzr workflow

[Lennart Borgman]

On Wed, Jan 13, 2010 at 5:18 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Wed, 13 Jan 2010 04:29:51 +0100
>>
>> It would be very good if someone pointed out on the wiki page where
>> (and perhaps how) you build Emacs. Do you do that in the trunk
>> directory
>
> Yes.
>
>> Is there anything special to consider?
>
> No.  Just do it as usual.

Thanks Eli.

Maybe it should be pointed out somewhere? I am not sure.

Re: bzr workflow

[Jan D.]

On 2010-01-12 20:41, Eli Zaretskii wrote:
>> Date: Tue, 12 Jan 2010 10:39:44 +0100
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> Cc: emacs-devel@gnu.org
>>
>> you still have to do make bootstrap again, and that is where time
>> goes.
>
> ??? On what OS?  It takes about 20 minutes on MS-Windows (which is
> indeed painful), but on GNU/Linux I'm done in 5.

Takes about 10-15 minutes for me on GNU/Linux.  My machine is a couple 
of generations old.

>
> Of course, that's not to say that one should bootstrap every hour, but
> if you need to do it every now and then, when you decide that another
> branch is in order...
>
> Furthermore, there are Bazaar tricks to have co-located branches, in
> which case you don't need to bootstrap at all.

I'll have to read up on those, sounds useful.

	Jan D.

Re: bzr workflow

[Óscar Fuentes]

Karl Fogel <kfogel@red-bean.com> 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? :-)

Personally, I prefer the conceptual simplicity of using trunk/ as the
gateway to upstream and do not overload it with other uses. It costs
nothing to bind quickfixes/ to upstream as trunk/ already is. I think
that if people use trunk/ for hacking, eventually it will get polluted
by half done quickfixes and will inhibit the use of feature branches
(because you need to clean up trunk/ before merging the feature branch
into upstream, etc), thus involuntarily encouraging a disorganized
personal development model, as was the case with CVS.

-- 
Óscar

Re: bzr workflow

[Stephen J. Turnbull]

Lennart Borgman writes:

 > >> It would be very good if someone pointed out on the wiki page where
 > >> (and perhaps how) you build Emacs. Do you do that in the trunk
 > >> directory
 > >
 > > Yes.
 > >
 > >> Is there anything special to consider?
 > >
 > > No.  Just do it as usual.
 > 
 > Thanks Eli.
 > 
 > Maybe it should be pointed out somewhere? I am not sure.

I don't think so.  There should not be any problems related to
building, *except* that the workflow common in "small" projects of
using "bzr branch" a lot without a shared repository should be avoided
in Emacs because the overhead of "make bootstrap" is noticable, and
unnecessary with an appropriate workflow.

I think you're the first person I've seen to worry about it, so I
don't think it's a FAQ.  When EmacsForBzrDevs is updated, we can just
add "You can just build and test as usual in the 'trunk' branch if you
use it for quick fixes."

Re: bzr workflow

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>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.

I've revamped http://www.emacswiki.org/emacs/BzrForEmacsDevs
accordingly.  Review and edits welcome.

-Karl