Re: GNU Emacs is on Bazaar now.

[Karl Fogel <kfogel@red-bean.com>]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>>> A separate question is, is this a *good* procedure for quick fixes?
>>
>> Just commit and push them.  There is no point in using a special branch.
>
> It depends on how quick your quickfix is.
>
> If you start editing the trunk mirror expecting to finish on a few
> minutes, but you slowly realize that the issue is not so simple, or some
> other urgent task arises ("you broke the build, fix it asap!" etc) you
> will have to deal with a polluted gateway to upstream, which is a
> inconvenience (move away your "quick" changes, revert modified files,
> and later recover the changes. `bzr shelve' can be handy here, but I
> don't recommend it to beginners.)

This is one reason we recommended the separate 'quickfix' branch --
because you never know when a one-commit quick fix will turn into an
N-commit quick fix.

> Given the slow commit rate on the Emacs project, I see no problem using
> the quickfixes branch on a CVS-like way: bind it to upstream and
>
> bzr update
> <hack, hack, hack>
> bzr update
> <maybe solve conflicts>
> bzr commit -m "fixed bug #2434"
>
> It is very likely that this works fine with VC.

Did you see the part in http://www.emacswiki.org/emacs/BzrForEmacsDevs
that says this?:

  > 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://<membername>@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.

Is that relevant to what you are proposing above?

-Karl