GNU Emacs is on Bazaar now.

GNU Emacs is on Bazaar now.

[Karl Fogel]

In case you missed it: GNU Emacs is on Bazaar now.  Please see
http://www.emacswiki.org/emacs/BzrForEmacsDevs for how to (re)obtain
your development sources from Bazaar.

The CVS repository is still around for read-only access (so 'cvs diff'
can tell you of any uncommitted local changes, for example).

Thanks to many people for pitching in on this transition, but especially
to Andreas Schwab, Jason Earl, Sylvain Beucler, and Stephen Turnbull.

-Karl

Re: GNU Emacs is on Bazaar now.

[Kenichi Handa]

In article <87d4206n80.fsf@canonical.com>, Karl Fogel <karl.fogel@canonical.com> writes:

> In case you missed it: GNU Emacs is on Bazaar now.  Please see
> http://www.emacswiki.org/emacs/BzrForEmacsDevs for how to (re)obtain
> your development sources from Bazaar.

I followed that page and created "quickfixex" branch.  Then,
I editted src/ChangeLog to add entries I forgot last time,
saved the file, and typed C-x v v C-c C-c.  Then I noticed
that "C-x v v C-c C-c" is enough to commit in CVS, but
perhaps not in Bazaar.  The above wiki page doesn't describe
what to do from Emacs to finish committing.  Should I do
this manually?

% bzr commit -m 'Add entries in ChangeLog'

---
Kenichi Handa
handa@m17n.org

Re: GNU Emacs is on Bazaar now.

[Karl Fogel]

Kenichi Handa <handa@m17n.org> writes:
>> In case you missed it: GNU Emacs is on Bazaar now.  Please see
>> http://www.emacswiki.org/emacs/BzrForEmacsDevs for how to (re)obtain
>> your development sources from Bazaar.
>
> I followed that page and created "quickfixex" branch.  Then,
> I editted src/ChangeLog to add entries I forgot last time,
> saved the file, and typed C-x v v C-c C-c.  Then I noticed
> that "C-x v v C-c C-c" is enough to commit in CVS, but
> perhaps not in Bazaar.  The above wiki page doesn't describe
> what to do from Emacs to finish committing.  Should I do
> this manually?
>
> % bzr commit -m 'Add entries in ChangeLog'

You should do whatever the wiki page says; it is written from a
command-line perspective.  (I don't know what directory you intend the
above to run in, so I can't answer your question as asked.  The idea is
that you should merge your change from quickfixes to trunk, then commit
trunk -- since trunk is bound to upstream, the commit there will push
the changes to the upstream master.)

Anyone should go ahead and document the VC commands if they know them,
by the way.  For various reasons (having to do with spending much of my
time running development versions of version control systems), I got out
of the habit of using VC years ago, so I couldn't document VC on that
wiki page.

Best,
-Karl

Re: GNU Emacs is on Bazaar now.

[Kenichi Handa]

Thank you for the quick responce.

In article <87637r610w.fsf@red-bean.com>, Karl Fogel <kfogel@red-bean.com> writes:

> Kenichi Handa <handa@m17n.org> writes:
>>> In case you missed it: GNU Emacs is on Bazaar now.  Please see
>>> http://www.emacswiki.org/emacs/BzrForEmacsDevs for how to (re)obtain
>>> your development sources from Bazaar.
> >
> > I followed that page and created "quickfixex" branch.  Then,
> > I editted src/ChangeLog to add entries I forgot last time,
> > saved the file, and typed C-x v v C-c C-c.  Then I noticed
> > that "C-x v v C-c C-c" is enough to commit in CVS, but
> > perhaps not in Bazaar.  The above wiki page doesn't describe
> > what to do from Emacs to finish committing.  Should I do
> > this manually?
> >
> > % bzr commit -m 'Add entries in ChangeLog'

> You should do whatever the wiki page says; it is written from a
> command-line perspective.

It says "Now you start editing. When you are done:".  For my
finger, "when you are done" meant "C-x C-s C-x v v C-c C-c"
in CVS and VC, and it was done before I realize that I'm now
in Bazaar.  :-(

> (I don't know what directory you intend the
> above to run in, so I can't answer your question as asked.

I'm now in "emacs/quickfixes" directory.

> The idea is
> that you should merge your change from quickfixes to trunk, then commit
> trunk -- since trunk is bound to upstream, the commit there will push
> the changes to the upstream master.)

Hmmm, ok, by follwoing the wiki page, I did these:

% bzr commit -m 'Add new entries to ChangeLog'
% cd ../trunk
% bzr pull
% bzr merge ../quickfixes
% bzr commit -m 'Merge: add new entries to ChangeLog'

I hope that is the right way.

But I have two questiongs.

Why do I need to supply similar comments twice?  Is it the
convention to follow that the second comment starts with
"Merge: ..."?

In CVS age, we don't add comments for changes of ChangeLog
file.  But bzr claims as below:

bzr: ERROR: empty commit message specified

when I do something like "% bzr commit -m ''".  Isn't it avoidable?

> Anyone should go ahead and document the VC commands if they know them,
> by the way.

I appreciate such a work very much.  The above procedure is
toooo annoying compared with the C-x v v C-c C-c in CVS age.

---
Kenichi Handa
handa@m17n.org

Re: GNU Emacs is on Bazaar now.

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> In CVS age, we don't add comments for changes of ChangeLog
> file.

You never commit Changelog separately.

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: GNU Emacs is on Bazaar now.

[Juanma Barranquero]

On Mon, Dec 28, 2009 at 09:52, Andreas Schwab <schwab@linux-m68k.org> wrote:

> You never commit Changelog separately.

Unless you're committing just changes to the ChangeLog (fixes, typos,
etc.). But in that case, there should be a commit message.

    Juanma

Re: GNU Emacs is on Bazaar now.

[Kenichi Handa]

In article <m23a2vtr9o.fsf@whitebox.home>, Andreas Schwab <schwab@linux-m68k.org> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > In CVS age, we don't add comments for changes of ChangeLog
> > file.

> You never commit Changelog separately.

Ah, hmmm.... ok.   Here's another question.

For instance, I recently committed these changes in CVS
(just before it becomes readonly)

2009-12-25  Kenichi Handa  <handa@m17n.org>

	* composite.h (composition_adjust_point): Update prototype.

	* composite.c (composition_reseat_it): Don't make a composition
	spanning over point.
	(CHAR_COMPOSABLE_P): Treat U+200C (ZWNJ) and U+200D (ZWJ) as
	composable characters.
	(composition_adjust_point): New arg NEW_PT.  Callers changed.

	* keyboard.c (command_loop_1): Force redisplay if the last point
	was within a composition.
	(adjust_point_for_property): Don't adjust point for automatic
	composition when called after buffer modification.

At that time, each changed file got it's own CVS log because
I committed each file with C-x v v while supplying its own
log by using C-c C-a.

Now with bazaar, according to the wiki page, it seems that I
must commit all files at once with a single log, and thus
all changed files are given the same log.  Is that true?  Is
that the right thing?

If so, is there any convention about the format of the log?
Can I use a relevant part of ChangeLog file as is?

---
Kenichi Handa
handa@m17n.org

Re: GNU Emacs is on Bazaar now.

[Juanma Barranquero]

On Mon, Dec 28, 2009 at 12:45, Kenichi Handa <handa@m17n.org> wrote:

> Now with bazaar, according to the wiki page, it seems that I
> must commit all files at once with a single log, and thus
> all changed files are given the same log.  Is that true?  Is
> that the right thing?

Yes.

> If so, is there any convention about the format of the log?
> Can I use a relevant part of ChangeLog file as is?

Yes, but it is useful to start the commit log with a one-line
description of the changes, because there are commands to show the
commits with their comments in "single line mode". For example, I
committed a change for vc-git, and the ChangeLog entry was this:

2009-12-28  Juanma Barranquero  <lekktu@gmail.com>

	Supersede color.diff settings in git log (bug#5211).

	* vc-git.el (vc-git-print-log): Pass "--no-color" to log to avoid
	escape chars in its output when the user has color.diff set to `always'.
	This fix works on git 1.4.2 and newer (released on 2006-08-13).

For the commit message I uses just the first line, but for more
extensive changes I would've used the whole ChangeLog entry.

Now, using "bzr log -l10 --line", you get:

99201: Juanma Barranquero 2009-12-28 [merge] Supersede color.diff
settings in git log (bug#5211).
99200: Juanma Barranquero 2009-12-28 [merge] Update .bzrignore.
99199: Juanma Barranquero 2009-12-28 Update autoload checksum.
99198: Karl Fogel 2009-12-27 [merge] Merge: update nt/INSTALL for
CVS->Bazaar switchover too.
99197: Karl Fogel 2009-12-27 [merge] Merge: document that we are on Bazaar now.
99196: Andreas Schwab 2009-12-27 Add .bzrignore
99195: Chong Yidong 2009-12-27 * minibuf.c (Fall_completions): Minor
optimization.
99194: Kevin Ryde 2009-12-26 * man.el
99193: Kevin Ryde 2009-12-26 (Man-bgproc-sentinel): When "-k foo"
produces no output show error
99192: Kevin Ryde 2009-12-26 Tweak a comment: it's man-db on gnu/linux
which agrees with posix that


    Juanma

Re: GNU Emacs is on Bazaar now.

[Kenichi Handa]

In article <f7ccd24b0912280408v58fe4d70j145ad8edefa7f32c@mail.gmail.com>, Juanma Barranquero <lekktu@gmail.com> writes:

> Yes, but it is useful to start the commit log with a one-line
> description of the changes, because there are commands to show the
> commits with their comments in "single line mode". For example, I
> committed a change for vc-git, and the ChangeLog entry was this:

> 2009-12-28  Juanma Barranquero  <lekktu@gmail.com>

> 	Supersede color.diff settings in git log (bug#5211).

> 	* vc-git.el (vc-git-print-log): Pass "--no-color" to log to avoid
> 	escape chars in its output when the user has color.diff set to `always'.
> 	This fix works on git 1.4.2 and newer (released on 2006-08-13).

> For the commit message I uses just the first line, but for more
> extensive changes I would've used the whole ChangeLog entry.

> Now, using "bzr log -l10 --line", you get:

> 99201: Juanma Barranquero 2009-12-28 [merge] Supersede color.diff
> settings in git log (bug#5211).
> 99200: Juanma Barranquero 2009-12-28 [merge] Update .bzrignore.
> 99199: Juanma Barranquero 2009-12-28 Update autoload checksum.
> 99198: Karl Fogel 2009-12-27 [merge] Merge: update nt/INSTALL for
> CVS->Bazaar switchover too.
> 99197: Karl Fogel 2009-12-27 [merge] Merge: document that we are on Bazaar now.
> 99196: Andreas Schwab 2009-12-27 Add .bzrignore
> 99195: Chong Yidong 2009-12-27 * minibuf.c (Fall_completions): Minor
> optimization.
> 99194: Kevin Ryde 2009-12-26 * man.el
> 99193: Kevin Ryde 2009-12-26 (Man-bgproc-sentinel): When "-k foo"
> produces no output show error
> 99192: Kevin Ryde 2009-12-26 Tweak a comment: it's man-db on gnu/linux
> which agrees with posix that

Ah, I see.  Thank you for the detailed explanation.

---
Kenichi Handa
handa@m17n.org

Re: GNU Emacs is on Bazaar now.

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> Now with bazaar, according to the wiki page, it seems that I
> must commit all files at once with a single log, and thus
> all changed files are given the same log.  Is that true?  Is
> that the right thing?

Each commit should contain a single, logically complete change, with the
commit message describing it.  That is independent of the underlying
VCS.

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: GNU Emacs is on Bazaar now.

[Xavier Maillard]

   Kenichi Handa <handa@m17n.org> writes:

   > Now with bazaar, according to the wiki page, it seems that I
   > must commit all files at once with a single log, and thus
   > all changed files are given the same log.  Is that true?  Is
   > that the right thing?

   Each commit should contain a single, logically complete change, with the
   commit message describing it.  That is independent of the underlying
   VCS.

In the RDBMS world, it is mroe or less an ACID transaction.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Kenichi Handa writes:

 > For instance, I recently committed these changes in CVS
 > (just before it becomes readonly)
 > 
 > 2009-12-25  Kenichi Handa  <handa@m17n.org>
 > 
 > 	* composite.h (composition_adjust_point): Update prototype.
 > 
 > 	* composite.c (composition_reseat_it): Don't make a composition
 > 	spanning over point.
 > 	(CHAR_COMPOSABLE_P): Treat U+200C (ZWNJ) and U+200D (ZWJ) as
 > 	composable characters.
 > 	(composition_adjust_point): New arg NEW_PT.  Callers changed.
 > 
 > 	* keyboard.c (command_loop_1): Force redisplay if the last point
 > 	was within a composition.
 > 	(adjust_point_for_property): Don't adjust point for automatic
 > 	composition when called after buffer modification.
 > 
 > At that time, each changed file got it's own CVS log because
 > I committed each file with C-x v v while supplying its own
 > log by using C-c C-a.
 > 
 > Now with bazaar, according to the wiki page, it seems that I
 > must commit all files at once with a single log, and thus
 > all changed files are given the same log.  Is that true?

It's true that all files committed at one time get the same VCS log.

 > Is that the right thing?

Yes.

There are alternatives that are closer to your CVS workflow.  However,
some involve per-file commits.  Those will probably be opposed by many
developers because they will make the VCS logs harder to read and
understand.  There are also tools that allow you to manage changes on
a piece by piece basis.  Then you finish by grouping them into a
single commit.  The disadvantage to those tools is that they will
require additional effort on your part to install and learn them.

If adjusting to this style is really uncomfortable for you, we can
discuss the options.

 > If so, is there any convention about the format of the log?
 > Can I use a relevant part of ChangeLog file as is?

Reusing the ChangeLog entry is very common in other projects that use
ChangeLogs.  A good Emacs ChangeLog entry will generally correspond to
a single commit in Bazaar, so it can be reused for the VCS log for
that commit.  As Juanma says, it's very useful to the readers to
provide a one-line summary at the top of each entry.

Eg, the ChangeLog entry quoted above looks like it describes a set of
changes that should constitute a single commit[1], and that log would be
in good style if you add a summary, such as "Improve redisplay and
point handling in character composition".


Footnotes: 
[1]  The change to CHAR_COMPOSABLE_P might better be split out into a
separate commit, unless that change is needed because of the other
changes.

Re: GNU Emacs is on Bazaar now.

[Juanma Barranquero]

On Mon, Dec 28, 2009 at 14:51, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> Footnotes:
> [1]  The change to CHAR_COMPOSABLE_P might better be split out into a
> separate commit, unless that change is needed because of the other
> changes.

That's an important point. Currently it's common to see commits that
introduce unrelated changes, or changes that, though related, are in
fact independently useful. Some projects (git, for example) have a
policy of dividing large changes into meaningful chunks, and the
result is quite readable, and much more easy to debug (via bisect) or
revert.

    Juanma

Re: GNU Emacs is on Bazaar now.

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> I followed that page and created "quickfixex" branch.

It doesn't make sense to create a branch for every little commit.

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: GNU Emacs is on Bazaar now.

[Juanma Barranquero]

On Mon, Dec 28, 2009 at 10:19, Andreas Schwab <schwab@linux-m68k.org> wrote:

> It doesn't make sense to create a branch for every little commit.

The current recommended practice (in the BazarForEmacsDevs document)
is to have a quickfixes/ branch for such kind of small changes, and
never use the trunk/ branch directly (except to merge ../quickfixes or
the task branch and then commit).

    Juanma

Re: GNU Emacs is on Bazaar now.

[Kenichi Handa]

In article <m2r5qfsbg5.fsf@whitebox.home>, Andreas Schwab <schwab@linux-m68k.org> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > I followed that page and created "quickfixex" branch.

> It doesn't make sense to create a branch for every little commit.

No, I'm not going to do that.  I'll use that branch for
"One-Off Change" repeatedly.  Isn't that recommended by the
wiki page?

---
Kenichi Handa
handa@m17n.org

Re: GNU Emacs is on Bazaar now.

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> In article <m2r5qfsbg5.fsf@whitebox.home>, Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Kenichi Handa <handa@m17n.org> writes:
>> > I followed that page and created "quickfixex" branch.
>
>> It doesn't make sense to create a branch for every little commit.
>
> No, I'm not going to do that.  I'll use that branch for
> "One-Off Change" repeatedly.

That's just the same.

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: GNU Emacs is on Bazaar now.

[Kenichi Handa]

In article <m2k4w7s3py.fsf@whitebox.home>, Andreas Schwab <schwab@linux-m68k.org> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > In article <m2r5qfsbg5.fsf@whitebox.home>, Andreas Schwab <schwab@linux-m68k.org> writes:
> >
>>> Kenichi Handa <handa@m17n.org> writes:
>>> > I followed that page and created "quickfixex" branch.
> >
>>> It doesn't make sense to create a branch for every little commit.
> >
> > No, I'm not going to do that.  I'll use that branch for
> > "One-Off Change" repeatedly.

> That's just the same.

??? What is the same with what?

---
Kenichi Handa
handa@m17n.org

Re: GNU Emacs is on Bazaar now.

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> In article <m2k4w7s3py.fsf@whitebox.home>, Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Kenichi Handa <handa@m17n.org> writes:
>> > In article <m2r5qfsbg5.fsf@whitebox.home>, Andreas Schwab <schwab@linux-m68k.org> writes:
>> >
>>>> Kenichi Handa <handa@m17n.org> writes:
>>>> > I followed that page and created "quickfixex" branch.
>> >
>>>> It doesn't make sense to create a branch for every little commit.
>> >
>> > No, I'm not going to do that.  I'll use that branch for
>> > "One-Off Change" repeatedly.
>
>> That's just the same.
>
> ??? What is the same with what?

Making a branch for every little commit.

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: GNU Emacs is on Bazaar now.

[Karl Fogel]

Andreas Schwab <schwab@linux-m68k.org> writes:
> Kenichi Handa <handa@m17n.org> writes:
>>>>> > I followed that page and created "quickfixex" branch.
>>>>> It doesn't make sense to create a branch for every little commit.
>>> > No, I'm not going to do that.  I'll use that branch for
>>> > "One-Off Change" repeatedly.
>>> That's just the same.
>> ??? What is the same with what?
> Making a branch for every little commit.

What we have here is a failure to communicate :-).

Currently, BzrForEmacsDevs recommends keeping a 'trunk' branch (used for
merging from other branches and for committing to upstream, but never
used for development) and a 'quickfixes' branch (for quick little fixes,
where you don't want to have to create a whole new branch each time).

The document recommends that 'quickfixes' be treated like any other
non-trunk local branch: you keep it up-to-date, you commit changes
there, and when ready, you merge it into trunk and then commit in trunk.
The only thing special about it is that it persists basically forever --
unlike feature branches, which you usually remove when done.

So by using 'quickfixes', Kenichi is following the recommended
procedure.

A separate question is, is this a *good* procedure for quick fixes?

Kenichi has a point: for a simple typo fix, it's annoying to have to
commit it in quickfixes, and then go merge it into trunk and commit it
again (with its own log message beginning with "Merge: ").  It would be
easier to just make the change in trunk and commit from there.  However,
I wasn't sure what complications might arise from doing that ('trunk' is
a bound branch), so we recommended a very conservative, very safe
procedure.

We can certainly tweak the instructions, if they don't work well for
certain situations!  I just want to make sure we don't recommend any
methods that make it too easy to mess up history or shoot oneself in the
foot, that's all.  Does anyone know a better workflow for quick fixes?

-Karl

Re: GNU Emacs is on Bazaar now.

[Andreas Schwab]

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

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: GNU Emacs is on Bazaar now.

[Karl Fogel]

Andreas Schwab <schwab@linux-m68k.org> writes:
> Karl Fogel <kfogel@red-bean.com> 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.

Andreas, have you read BzrForEmacsDevs?

In the scenario there, 'trunk' is a bound branch.  So this would be only
a 'commit', no need for a separate command to push.  (But I'd feel more
comfortable if you checked over the entire procedure documented there,
to make sure there are no other problems lurking in the wings if one
uses the 'trunk' branch, as currently set up, for direct development of
quick fixes.)

-Karl

Re: GNU Emacs is on Bazaar now.

[Giorgos Keramidas]

On Mon, 28 Dec 2009 17:24:29 -0500, Karl Fogel <kfogel@red-bean.com> wrote:
>Andreas Schwab <schwab@linux-m68k.org> writes:
>>Karl Fogel <kfogel@red-bean.com> 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.
>
> Andreas, have you read BzrForEmacsDevs?
>
> In the scenario there, 'trunk' is a bound branch.  So this would be
> only a 'commit', no need for a separate command to push.  (But I'd
> feel more comfortable if you checked over the entire procedure
> documented there, to make sure there are no other problems lurking in
> the wings if one uses the 'trunk' branch, as currently set up, for
> direct development of quick fixes.)

One of the things that seem annoying when people make small changes
using a DVCS is the merge step that is required if the remote trunk has
already moved on.  It seems silly to have merge commits for tiny and
simple commits that modify a few lines in one place.  The inevitable
"merge pollution" of the branch history can be avoided most of the time
by 'rebasing' the changes inside the quickfixes branch before pulling
them into the trunk.

The 'rebase' plugin of bazaar[1] may help a lot with this sort of
workflow.  Using this plugin one can keep making small changes in the
quick fixes, testing them outside of the bound 'trunk' copy and then
pulling into the local & bound trunk when they are done, FSVO "done".

[1] http://wiki.bazaar.canonical.com/Rebase

Installing and using the rebase plugin is easy on UNIX.  One can start
by making a ~/.bazaar/plugins directory and copying the rebase plugin
itself inside it:

    $ mkdir ~/.bazaar/plugins
    $ cd ~/.bazaar/plugins
    $ bzr branch http://people.samba.org/bzr/jelmer/bzr-rebase/trunk rebase

This will install and make visible a few new commands:

    $ bzr help commands | grep '^rebase'
    rebase                  Re-base a branch. [rebase]
    rebase-abort            Abort an interrupted rebase. [rebase]
    rebase-continue         Continue an interrupted rebase after resolving
    rebase-foreign          Rebase revisions based on a branch created with a
    rebase-todo             Print list of revisions that still need to be replayed
    $

Now small changes can be committed to the quickfixes branch as described
in BzrForEmacsDevs.  When the small change is committed to 'quickfixes',
we can now:

  * Pull any trunk changes from savannah

        $ cd ../trunk
        $ bzr pull

  * Go back into the 'quickfixes' branch and rebase the small change on
    top of the latest local trunk (which should be up-to-date with the
    savannah copy of the same branch now):

        $ cd ../quickfixes
        $ bzr rebase

If all goes well the local change of 'quickfixes' will be rebased on top
of the trunk, eliminating the need of "bzr merge" for such a small
commit.  In this case bazaar will report something like:

    Committing to: ~/bzr/emacs/quickfixes/
    modified lisp/foo.el
    Committed revision 105601.

If there are conflicts, rebase will temporarily stop and leave conflict
markers in the files that require manual intervention.  After editing
the files and resolving the conflicts, one can run:

    $ bzr resolve lisp/foo.el
    $ bzr rebase-continue

I personally find this sort of workflow a bit useful when dealing with
tiny changesets.  The final branch history of trunk is going to be much
"cleaner" if we don't have thousands of tiny changesets followed by a
merge commit after each small one.  But this is just a personal choice
and it is heavily influenced by my experience with changeset rebasing in
other DVCS's.

Re: GNU Emacs is on Bazaar now.

[Juanma Barranquero]

On Tue, Dec 29, 2009 at 02:26, Giorgos Keramidas
<keramida@ceid.upatras.gr> wrote:

> Installing and using the rebase plugin is easy on UNIX.

On the standalone installation for Windows, rebase is already included...

> This will install and make visible a few new commands:
>
>    $ bzr help commands | grep '^rebase'
>    rebase                  Re-base a branch. [rebase]
>    rebase-abort            Abort an interrupted rebase. [rebase]
>    rebase-continue         Continue an interrupted rebase after resolving
>    rebase-foreign          Rebase revisions based on a branch created with a
>    rebase-todo             Print list of revisions that still need to be replayed
>    $

though it seems to lack rebase-foreign:

C:\> bzr help commands | grep ^rebase
rebase                  Re-base a branch. [rebase]
rebase-abort            Abort an interrupted rebase. [rebase]
rebase-continue         Continue an interrupted rebase after resolving
conflicts. [rebase]
rebase-todo             Print list of revisions that still need to be
replayed as part of the  [rebase]

> I personally find this sort of workflow a bit useful when dealing with
> tiny changesets.  The final branch history of trunk is going to be much
> "cleaner" if we don't have thousands of tiny changesets followed by a
> merge commit after each small one.

A way to do the equivalent of "git rebase -i" would be nice, too.

    Juanma

Re: GNU Emacs is on Bazaar now.

[Giorgos Keramidas]

On Tue, 29 Dec 2009 03:08:07 +0100, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Tue, Dec 29, 2009 at 02:26, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
>> I personally find this sort of workflow a bit useful when dealing with
>> tiny changesets.  The final branch history of trunk is going to be much
>> "cleaner" if we don't have thousands of tiny changesets followed by a
>> merge commit after each small one.
>
> A way to do the equivalent of "git rebase -i" would be nice, too.

I've only been using "bzr rebase" for a few hours.  I don't see anything
that resembles "git rebase -i" in the documentation of the current bzr
plugin, so it's possible that there is no equivalent.

It's conceivable that a careful combination of "bzr shelve" and the
existing "bzr rebase" functionality may be one way to achieve similar
results with "git rebase -i".  If this turns out to be too complex, we
should probably focus on an easy workflow for small changes first and
leave more complex history manipulation tricks for later.

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

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

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.

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Karl Fogel]

Ó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

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

Karl Fogel <kfogel@red-bean.com> writes:

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

I think that Andread was proposing to use the local trunk mirror as the
place for editing the quickfixes. You and me agree that that is
undesirable.

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

No, because you are committing to upstream, not pushing, i.e. every
commit just adds one history item to upstream on top of the previous,
without attached or "hidden" revisions, which is perfectly fine for
simple changes. Actually, it is the opposite scenario of the one
mentioned on the warning you quoted, as it keeps a synchronized linear
history between the involved branches.

See this hypothetical log entries on upstream trunk:

with commit on a bound quickfixes branch:

34823 fixed bug #2423

with commit on an unbound quickfixes branch + merge&commit on a bound
local mirror:

34823 fixed bug #2423  (that's the commit to upstream from the local mirror)
33823.33822 fixed bug #2423 (that's the merged local quickfixes commit)

The last example has one redundant (although hidden by default) log
entry, requires more commands and suffers from the "double commit"
nuisance that Kenichi Handa mentioned at the beginning of this thread.

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Karl Fogel]

Óscar Fuentes <ofv@wanadoo.es> writes:
> See this hypothetical log entries on upstream trunk:
>
> with commit on a bound quickfixes branch:
>
> 34823 fixed bug #2423

Can you describe precisely whaht "bound quickfixes branch" means, in
terms of the exact configuration one would do?

-K

> with commit on an unbound quickfixes branch + merge&commit on a bound
> local mirror:
>
> 34823 fixed bug #2423  (that's the commit to upstream from the local mirror)
> 33823.33822 fixed bug #2423 (that's the merged local quickfixes commit)
>
> The last example has one redundant (although hidden by default) log
> entry, requires more commands and suffers from the "double commit"
> nuisance that Kenichi Handa mentioned at the beginning of this thread.

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

Karl Fogel <kfogel@red-bean.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>> See this hypothetical log entries on upstream trunk:
>>
>> with commit on a bound quickfixes branch:
>>
>> 34823 fixed bug #2423
>
> Can you describe precisely whaht "bound quickfixes branch" means, in
> terms of the exact configuration one would do?

The quickfixes branch will be bound to upstrem's trunk, in a similar way
the local mirror is.

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > No, because you are committing to upstream, not pushing, i.e. every
 > commit just adds one history item to upstream on top of the previous,
 > without attached or "hidden" revisions, which is perfectly fine for
 > simple changes.

Except in the case of a conflict.  Can you confirm that works smoothly
with the proposed "bzr update" workflow?

 > The last example has one redundant (although hidden by default) log
 > entry, requires more commands and suffers from the "double commit"
 > nuisance that Kenichi Handa mentioned at the beginning of this thread.

This can be easily automated, though.

And what happens if he actually uses a feature branch?  Ken'ichi works
on very invasive stuff (Mule, which has its fingers in all the
lowlevel buffer stuff and redisplay), and is likely to appreciate the
isolation that feature branches provide, once he's used them.  I think
there's a lot of room for icky things[tm] to happen if the bzr-update-
and-work-on-trunk discipline is mixed with the push-through-a-dedicated-
trunk-mirror-branch discipline.

Re: GNU Emacs is on Bazaar now.

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> isolation that feature branches provide, once he's used them.  I think
> there's a lot of room for icky things[tm] to happen if the bzr-update-
> and-work-on-trunk discipline is mixed with the push-through-a-dedicated-
> trunk-mirror-branch discipline.

Right -- cognitive load is a factor here.

The nice thing about the 'quickfixes' branch (as currently documented)
is that you use it the same way you'd use any other feature or bugfix
branch.  This allows the developer to form safe habits.  Mixing methods
increases the risk of something icky happening.

(I'm not saying we can't document other workflows; I'm just trying to
point out all the reasoning behind the workflow currently documented, so
we don't travel the same road many times.)

-Karl

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Óscar Fuentes writes:
>
>  > No, because you are committing to upstream, not pushing, i.e. every
>  > commit just adds one history item to upstream on top of the previous,
>  > without attached or "hidden" revisions, which is perfectly fine for
>  > simple changes.
>
> Except in the case of a conflict.  Can you confirm that works smoothly
> with the proposed "bzr update" workflow?

That is not different from CVS or Subversion: you update before commit,
you get conflicts, you resolve them, you commit.

>  > The last example has one redundant (although hidden by default) log
>  > entry, requires more commands and suffers from the "double commit"
>  > nuisance that Kenichi Handa mentioned at the beginning of this thread.
>
> This can be easily automated, though.
>
> And what happens if he actually uses a feature branch?

Then he should use the adequate workflow for a feature branch.

[snip]
> I think there's a lot of room for icky things[tm] to happen if the
> bzr-update- and-work-on-trunk discipline is mixed with the
> push-through-a-dedicated- trunk-mirror-branch discipline.

Can you describe some of those icky things?

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > > And what happens if he actually uses a feature branch?
 > 
 > Then he should use the adequate workflow for a feature branch.

People DO NOT DO WHAT THEY SHOULD DO.  If they did, we wouldn't be
having this discussion.  Instead, they look for shortcuts, for
convenience, for the familiar.

 > [snip]
 > > I think there's a lot of room for icky things[tm] to happen if
 > > the bzr-update-and-work-on-trunk discipline is mixed with the
 > > push-through-a-dedicated-trunk-mirror-branch discipline.
 > 
 > Can you describe some of those icky things?

No.  If I could describe them, I wouldn't be so adamant about a
SINGLE, fairly simple, flexible, socially adapted workflow that works
for almost everybody.  I'd figure out a workflow that is more adapted
to existing Emacs usage, with a straightforward upgrade path to "full
tilt boogie" exploitation of advanced DVCS features.  Wouldn't you?

Why do I expect them?  Feel free to review the "how do I get myself
out of here" threads on any of the DVCS user lists if you must have
examples.  There are plenty on bazaar@canonical.com.

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Óscar Fuentes writes:
>
>  > > And what happens if he actually uses a feature branch?
>  > 
>  > Then he should use the adequate workflow for a feature branch.
>
> People DO NOT DO WHAT THEY SHOULD DO.  If they did, we wouldn't be
> having this discussion.  Instead, they look for shortcuts, for
> convenience, for the familiar.

I think that some people is looking for shortcuts because they find the
distributed workflow unnecessarily complex. Either they fail to
appreciate the benefits of the added complexity or they think that those
benefits are of no value for them.

>  > > I think there's a lot of room for icky things[tm] to happen if
>  > > the bzr-update-and-work-on-trunk discipline is mixed with the
>  > > push-through-a-dedicated-trunk-mirror-branch discipline.
>  > 
>  > Can you describe some of those icky things?
>
> No.  If I could describe them, I wouldn't be so adamant about a
> SINGLE, fairly simple, flexible, socially adapted workflow that works
> for almost everybody.  I'd figure out a workflow that is more adapted
> to existing Emacs usage, with a straightforward upgrade path to "full
> tilt boogie" exploitation of advanced DVCS features.  Wouldn't you?
>
> Why do I expect them?  Feel free to review the "how do I get myself
> out of here" threads on any of the DVCS user lists if you must have
> examples.  There are plenty on bazaar@canonical.com.

In short, there are "icky things" that you can't describe but are
extensively discussed on the mailing lists. Oh well.

As said on the past, my description of the centralized way is targeted
to *reduce* the problems *some* emacs hackers can experience on the
transition to bzr, and allow them to keep doing the really important
thing: keep contributing. You insist on that having the simpler workflow
documented actually creates problems, but so far failed to mention a
single serious issue with it.

Personally, if I were a hacker doing quick contributions to emacs (the
sort of thing that ends on one single commit), I would use the
centralized workflow.

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Kevin Rodgers]

Óscar Fuentes wrote:
> I think that some people is looking for shortcuts because they find the
> distributed workflow unnecessarily complex. Either they fail to
> appreciate the benefits of the added complexity or they think that those
> benefits are of no value for them.

Exactly.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: GNU Emacs is on Bazaar now.

[Juanma Barranquero]

On Tue, Dec 29, 2009 at 05:46, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Personally, if I were a hacker doing quick contributions to emacs (the
> sort of thing that ends on one single commit), I would use the
> centralized workflow.

And you would likely get some heat the nth time that you accidentally
committed half-done changes, incomplete changelog entries, partial
commits, etc. All the things that you can do in your local, non-bound
branch and then fix at your own pace before sending it upstream. At
least, I would (receive the heat, I mean, because I would likely do
these mistakes).

I know that I'm not saying anything that you don't know; also that
you've insisted that we're developing Emacs, not creating the
best-looking commit log ever. But it seems best to start recommending
safer, cleaner practices. People who knows better, knows enough to
bypass the recommendations.

    Juanma

Re: GNU Emacs is on Bazaar now.

[Karl Fogel]

Juanma Barranquero <lekktu@gmail.com> writes:
>On Tue, Dec 29, 2009 at 05:46, Óscar Fuentes <ofv@wanadoo.es> wrote:
>> Personally, if I were a hacker doing quick contributions to emacs (the
>> sort of thing that ends on one single commit), I would use the
>> centralized workflow.
>
>And you would likely get some heat the nth time that you accidentally
>committed half-done changes, incomplete changelog entries, partial
>commits, etc. All the things that you can do in your local, non-bound
>branch and then fix at your own pace before sending it upstream. At
>least, I would (receive the heat, I mean, because I would likely do
>these mistakes).
>
>I know that I'm not saying anything that you don't know; also that
>you've insisted that we're developing Emacs, not creating the
>best-looking commit log ever. But it seems best to start recommending
>safer, cleaner practices. People who knows better, knows enough to
>bypass the recommendations.

Remember, during the transition, the point of
http://www.emacswiki.org/emacs-en/BzrForEmacsDevs was to offer a
reliable, safe, and simple method for continuing to work.  That way, no
one would shoot themselves (or the project) in the foot while learning
how to use Bazaar.  This naturally involved compromises.

Soon, though, developers (like Kenichi Handa) will be more familiar and
comfortable with Bazaar.  Once that happens, they *will* start looking
for ways to get around annoyances -- such as the need to do two commits
with two log messages (!) even for simple typo changes.

This is inevitable; if we deny this reality, we simply make the doc less
useful.  We always expected there would be adjustments to the doc once
we actually started using Bazaar; now we're hitting the first of those.

So at some point, I think it might be good to add Oscar's proposed
bound-branch-for-really-truly-one-commit-fixes method to the
documentation, as an option.  The recipe needed to be simple for the
transition, but it can get a *little* more complicated after that.  We
could recommend that the branch be called "oneoffs" or something.

Óscar, does your proposed workflow look like this?:

  ### Prepare the branch:
  $ cd $DEVHOME/emacs
  $ bzr branch trunk oneoffs
  $ cd oneoffs
  $ echo "public_branch = sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/trunk" >> .bzr/branch/branch.conf
  $ bzr bind sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/trunk

  ### To make a truly one-off typo fix, do this:
  $ cd $DEVHOME/emacs/oneoffs
  $ bzr update
  $ <<< edit to make the change, & edit the appropriate ChangeLog >>>
  $ bzr update
  $ <<< resolve any conflicts >>>
  $ bzr commit -m "* README: Fix typo."

(I want to be absolutely clear on what we're talking about, before we
figure out whether and how to document it.)

-Karl

Re: GNU Emacs is on Bazaar now.

[Juanma Barranquero]

On Tue, Dec 29, 2009 at 16:54, Karl Fogel <kfogel@red-bean.com> wrote:

> Remember, during the transition, the point of
> http://www.emacswiki.org/emacs-en/BzrForEmacsDevs was to offer a
> reliable, safe, and simple method for continuing to work.  That way, no
> one would shoot themselves (or the project) in the foot while learning
> how to use Bazaar.  This naturally involved compromises.
>
> Soon, though, developers (like Kenichi Handa) will be more familiar and
> comfortable with Bazaar.  Once that happens, they *will* start looking
> for ways to get around annoyances -- such as the need to do two commits
> with two log messages (!) even for simple typo changes.

No problem. But I think many people is still struggling with
BzrForEmacsDevs. Adding more complexity at this moment is IMO a bit
premature.

    Juanma

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

Karl Fogel <kfogel@red-bean.com> writes:

[snip]

> Óscar, does your proposed workflow look like this?:

My proposed workflow is, in essence, the same as described on

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

You already link to it from your document, so I see no need to change
anything. The workflow you describe is a variation of mine: you branch
from the local mirror and use `bind' instead of a checkout, but the day
to day work is the same.

[snip]

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Tue, 29 Dec 2009 10:54:14 -0500
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Remember, during the transition, the point of
> http://www.emacswiki.org/emacs-en/BzrForEmacsDevs was to offer a
> reliable, safe, and simple method for continuing to work.  That way, no
> one would shoot themselves (or the project) in the foot while learning
> how to use Bazaar.  This naturally involved compromises.
> 
> Soon, though, developers (like Kenichi Handa) will be more familiar and
> comfortable with Bazaar.  Once that happens, they *will* start looking
> for ways to get around annoyances -- such as the need to do two commits
> with two log messages (!) even for simple typo changes.
> 
> This is inevitable; if we deny this reality, we simply make the doc less
> useful.

As I wrote several weeks ago (and was pounced upon), I don't see why
we need to spoon-feed experienced developers such as Handa-san.  I see
no need to wait until developers ``start looking for ways to get
around'', and tell them how to do that only then.  Describe the
options (not all of them, just a few useful ones) together with their
merits and demerits, and let each one make their own choices, like the
grown-ups they are.  The current ``need to know basis'' attitude of
keeping information off the docs lest developers will be confused is
almost unethical, pardon my French.

Re: GNU Emacs is on Bazaar now.

[Juanma Barranquero]

On Tue, Dec 29, 2009 at 19:08, Eli Zaretskii <eliz@gnu.org> wrote:

> The current ``need to know basis'' attitude of
> keeping information off the docs lest developers will be confused is
> almost unethical, pardon my French.

There's no hidden information: no one is prevented from reading the
Bazaar docs. It seems a bit silly to add to the introductory document
so much information that you're just rewriting the standard
documentation.

    Juanma

Re: GNU Emacs is on Bazaar now.

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 29 Dec 2009 19:09:55 +0100
> Cc: Karl Fogel <kfogel@red-bean.com>, ofv@wanadoo.es, emacs-devel@gnu.org
> 
> On Tue, Dec 29, 2009 at 19:08, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > The current ``need to know basis'' attitude of
> > keeping information off the docs lest developers will be confused is
> > almost unethical, pardon my French.
> 
> There's no hidden information: no one is prevented from reading the
> Bazaar docs. It seems a bit silly to add to the introductory document
> so much information that you're just rewriting the standard
> documentation.

Maybe I missed something, reading and re-reading both the User Guide
and the User Reference, but I didn't find that information there.
There's a short description of 3 workflows here:

  http://doc.bazaar.canonical.com/bzr.2.0/en/user-guide/bazaar_workflows.html

and in a few other pages in the User Guide, but there's no information
whatsoever about advantages and disadvantages of each possible setup.
For example, the issue that triggered this thread -- the need to
commit twice -- is never mentioned explicitly as an ``annoyance''.

And, of course, the upstream docs, being general and generic, can
never be focused enough for the Emacs project.

Re: GNU Emacs is on Bazaar now.

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> As I wrote several weeks ago (and was pounced upon), I don't see why
> we need to spoon-feed experienced developers such as Handa-san.  I see
> no need to wait until developers ``start looking for ways to get
> around'', and tell them how to do that only then.  Describe the
> options (not all of them, just a few useful ones) together with their
> merits and demerits, and let each one make their own choices, like the
> grown-ups they are.  The current ``need to know basis'' attitude of
> keeping information off the docs lest developers will be confused is
> almost unethical, pardon my French.

In my opinion, if someone (such as Handa or myself) is happy with VC and
the old CVS-style workflow, we should recommand the CVS-like solution
documented at

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

This is not a fancy as a true DVCS-style workflow, but as far as I can
tell it has the massive advantage that VC Just Works (tm).

Re: GNU Emacs is on Bazaar now.

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Karl Fogel <kfogel@red-bean.com>, ofv@wanadoo.es, lekktu@gmail.com,
>         emacs-devel@gnu.org
> Date: Tue, 29 Dec 2009 13:13:31 -0500
> 
> In my opinion, if someone (such as Handa or myself) is happy with VC and
> the old CVS-style workflow, we should recommand the CVS-like solution
> documented at
> 
>   http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs

That's fine with me.  But I _do_ want to use the distributed workflow
and have a local repository.  And I don't understand why I need to
wait until I bump into annoyances before I get to be told what are the
ways around them.

Re: GNU Emacs is on Bazaar now.

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>> In my opinion, if someone (such as Handa or myself) is happy with VC and
>> the old CVS-style workflow, we should recommand the CVS-like solution
>> documented at
>> 
>>   http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs
>
>That's fine with me.  But I _do_ want to use the distributed workflow
>and have a local repository.  And I don't understand why I need to
>wait until I bump into annoyances before I get to be told what are the
>ways around them.

That's not what's happening.

What's happening is that some us are thinking hard about how to write an
introductory doc in the most useful way -- by definition, that means
choosing what to leave out.  Naturally, we'll sometimes leave something
out that maybe we should have included.  We don't know in advance what
annoyances people will bump into; nor is it easy to gauge the cost (in
cognitive load on the reader) of putting too much stuff in.

If you want us to predict every developer's experience, or rewrite all
the Bazaar docs, well, that's above my pay grade.  We've gone to a great
deal of trouble to make the right compromises in a document that will
inevitably not be perfect for everyone; we've linked to another document
that explains the method you _do_ want; we are trying to be responsive
and responsible about adjusting the documentation based on feedback from
this list; above all, Bazaar is a free software project with its own
easily accessible documentation.  And your comment that you don't like
being used as a guinea pig?  Then go read the native Bazaar docs.  No
one's stopping you.

Very.  Slightly.  Ticked.  Off.  (but only slightly),
-Karl

Re: GNU Emacs is on Bazaar now.

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Tue, 29 Dec 2009 13:54:25 -0500
> Cc: ofv@wanadoo.es, lekktu@gmail.com, Chong Yidong <cyd@stupidchicken.com>,
> 	emacs-devel@gnu.org
> 
> We don't know in advance what annoyances people will bump into

In my reading of some of the stuff in this thread, the annoyances were
known, but solutions for them were not revealed on purpose, to avoid
some potential confusion.  Apologies if I misunderstood.

Re: GNU Emacs is on Bazaar now.

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>In my reading of some of the stuff in this thread, the annoyances were
>known, but solutions for them were not revealed on purpose, to avoid
>some potential confusion.  Apologies if I misunderstood.

I think you did misunderstand.

AFAIK, no one has withheld solutions to avoid confusing people.  Some of
us have sometimes declined to put certain solutions *into the
Emacs-specific intro doc we're maintaining*, on the grounds that we
didn't know (at that point) how widely useful the solution would be,
because the doc has to stay small enough to be digestible.  But that's
the same tradeoff any document must make.  It's not the same as
witholding solutions for the purpose you describe.  Where I can, I've
posted solutions on the list that I didn't (yet) put into the doc;
others have done so as well.

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Karl Fogel writes:
 > Eli Zaretskii <eliz@gnu.org> writes:
 > >In my reading of some of the stuff in this thread, the annoyances were
 > >known, but solutions for them were not revealed on purpose, to avoid
 > >some potential confusion.  Apologies if I misunderstood.
 > 
 > I think you did misunderstand.
 > 
 > AFAIK, no one has withheld solutions to avoid confusing people.

I agree with that.  I have opposed putting those (proposed and
*untested*) solutions into the document I have helped write to avoid
confusing *me*!

I think there's another point of misunderstanding here as well.  The
centralized features of bzr are designed to support a *project-wide*
centralized workflow (eg, with mandatory reviews and full testing of
*all* patches before pushing to the public mainline), *not* to help
people used to a CVS-imposed centralized workflow integrate gracefully
into a basically decentralized workflow.  I don't think anybody here
has experience with these halfway, make-it-easy-for-the-busy-developer
workflows.  Anyway, I don't, and so I cannot recommend them, and will
distance myself from any document that does.

Nor is the workflow Óscar describes as simple as it seems.  First, it
can't be used with vc yet because he implicitly assumes a commit-all-
related-changes-at-once workflow.  AFAIK at this point means using the
command line, not vc (compare to the workflow Handa-san described of
just C-x v v C-x b ... until all files are done).[1]

Second, he says he doesn't recommend it for larger changes; instead,
the feature branch workflow is what he recommends.  So Handa-san is
going to have to learn a workflow at least as complex as the one in
BzrForEmacsDevs in the fairly near future anyway (at least I hope he's
going to keep contributing major improvements to Mule at the current
pace!)

Finally, Karl says he's a little upset about these criticisms.  I'll
go beyond that.  Remember that Bazaar was chosen for purely political
reasons.  "We have no extremely experienced bzr users who can help
others" was *not* a consideration.  "The Bazaar docs are not much help
for Emacs devs" was *not* a consideration.  These things have come
back and caused y'all some inconvenebit you on the assince?  Don't blame me.


Footnotes: 
[1]  I know that multi-file features for vc are in progress, but it
won't be as easy as "C-x v v C-x b ... until done", and the UI is
likely to be more or less clumsy and unstable for several months at
least.

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:

[snip]

> Nor is the workflow Óscar describes as simple as it seems.  First, it
> can't be used with vc yet because he implicitly assumes a commit-all-
> related-changes-at-once workflow.  AFAIK at this point means using the
> command line, not vc (compare to the workflow Handa-san described of
> just C-x v v C-x b ... until all files are done).[1]

[snip]

> Footnotes: 
> [1]  I know that multi-file features for vc are in progress, but it
> won't be as easy as "C-x v v C-x b ... until done", and the UI is
> likely to be more or less clumsy and unstable for several months at
> least.

I don't know how the old VC worked as I always was a fan of PCL-CVS and
later of psvn. Maybe it was a great convenience to use C-x v v C-x b
instead of VC-dir to see all edited files and apply the same operation
to all files or to a subset of them. But right now VC-dir works very
well with Bazaar on the centralized workflow and Dan is being very quick
fixing the few bugs that arise and adding features.

Maybe I'm missing some piece of VC wizardly that is a pet feature of
Emacs hackers and that still clashes with changeset-oriented VCS ?

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Maybe I'm missing some piece of VC wizardly that is a pet feature of
> Emacs hackers and that still clashes with changeset-oriented VCS ?

I don't think so; it's just a matter of familiarity I think.

-miles

-- 
Neighbor, n. One whom we are commanded to love as ourselves, and who does all
he knows how to make us disobedient.

Re: GNU Emacs is on Bazaar now.

[Miles Bader]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
> [1]  I know that multi-file features for vc are in progress, but it
> won't be as easy as "C-x v v C-x b ... until done", and the UI is
> likely to be more or less clumsy and unstable for several months at
> least.

Eh?  It might have bugs (dunno) but it's worked pretty well for typical
usage for quite a while, and it's essentially the same interface people
have used for a long time with pcvs...

Anyway, it's absolutely a usable and reasonable thing to recommend
people use.

[Not that alternative interfaces wouldn't be nice too -- e.g. a "add
this buffer to the set to be committed with the next commit" command
(ESR had some sort of objection to such interfaces, but never gave any
substantive reason, and now that he's out of the picture, I don't see
why not).]

-Miles

-- 
Fast, small, soon; pick any 2.

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Miles Bader writes:

 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > > [1]  I know that multi-file features for vc are in progress, but it
 > > won't be as easy as "C-x v v C-x b ... until done", and the UI is
 > > likely to be more or less clumsy and unstable for several months at
 > > least.
 > 
 > Eh?  It might have bugs (dunno) but it's worked pretty well for typical
 > usage for quite a while, and it's essentially the same interface people
 > have used for a long time with pcvs...

OK, if so, then I retract my statement and recommend to Ken'ichi that
he try the other interface.

(I don't use it and I see a lot of traffic regarding UI issues with
vc-dir.  The "half-full" way to look at that is "people like it and
are recommending even better ways to use it", I guess. :-)

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Chong Yidong writes:

 >   http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs
 > 
 > This is not a fancy as a true DVCS-style workflow, but as far as I can
 > tell it has the massive advantage that VC Just Works (tm).

No, it does not.  It Just Works for the developer who uses it, but it
encourages a personal workflow that some other developers would rather
not see in the output of bzr log.

Cf. Andreas's posts.

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Chong Yidong writes:
>
>  >   http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs
>  > 
>  > This is not a fancy as a true DVCS-style workflow, but as far as I can
>  > tell it has the massive advantage that VC Just Works (tm).
>
> No, it does not.  It Just Works for the developer who uses it, but it
> encourages a personal workflow that some other developers would rather
> not see in the output of bzr log.
>
> Cf. Andreas's posts.

Oh my God. Really, really, really, why so much insistence on having

87344 Fixed bug #4223
87344.1 Fixed bug #4223

instead of just

87344 Fixed bug #4223

????

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > Oh my God. Really, really, really, why so much insistence on having
 > 
 > 87344 Fixed bug #4223
 > 87344.1 Fixed bug #4223
 > 
 > instead of just
 > 
 > 87344 Fixed bug #4223

First, because there is absolutely nobody insisting on that.  Take
your strawman elsewhere.

Second, because without changes in Handa-san's workflow, it will
actually look like this anyway:

87345 ChangeLog for 87344
87344 Fixed bug #4223

What Handa-san has done until now, according to his post, would
actually result in (for that case) something like

87344 ChangeLog: Fixed bug #4223
87343 Updated callers in quux.c
87342 Updated callers in baz.c
87341 Updated callers in bar.c
87340 Updated prototype in foo.h
87339 Added argument to snafoo in foo.c

The problem I'm pointing out is that *for Handa-san, exactly the same
personal workflow as in CVS* works fine with bzr, too.  He will not
notice any problems because in a CVS-alike workflow he probably
doesn't use "bzr log", he looks at the ChangeLog.  The ChangeLog will
look as it does in CVS.  But "bzr log -n1" will show the commits as
above, which is not very nice for *other* people who find that bzr's
advanced features improve *their* workflows.  Unfortunately, that's
the most likely outcome if he followed your original advice.

It was only later that you said "oh, of course he should change his
workflow so that he commits coherent changsets".  I'm sure he's
willing to do so if so advised, but that's not what you said in your
first post.  And rms, at least, has been opposed to asking anybody to
change their workflows until they're ready to do so.  Ditto, Eli Z.

It's not clear to me that there is a huge advantage to him if he has
to alter workflows anyway.  Some people might prefer to keep the "C-x
v v"-based workflow, and then "merge to mirror + commit to the remote
repo" as a separate step that they could do once a day, or once a week
for that matter.

In that case, we would see

87344 Merge: Fixed bug #4223
87343.6 ChangeLog: Fixed bug #4223
87343.5 Updated callers in quux.c
87343.4 Updated callers in baz.c
87343.3 Updated callers in bar.c
87343.2 Updated prototype in foo.h
87343.1 Added argument to snafoo in foo.c

which would by default (ie, just "bzr log") appear as

87344 Fixed bug #4223

of course.  This requires maintaining two branches, one for the actual
commits, one for merge and commit + push (unbound) or commit (bound).
But it does work fairly well for users of vc who use the "C-x v v C-x
b ... (repeat)" workflow, and with feature branches.  The only thing
it's really horrible for is the one-line, one-file fix -- and until
Emacs abandons ChangeLogs, those are really rare because the fix will
be accompanied by a log, unless the fix is in the ChangeLog itself.

Some folks wouldn't like that much, I imagine (ie, those who insist on
coherent changeset commits).

Finally, note that none of the above mentions the fact that if
Handa-san decides to do some extended work on a branch, he'll need to
learn the work branch + trunk mirror workflow anyway.

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> First, because there is absolutely nobody insisting on that.  Take
> your strawman elsewhere.

You snip the relevant content, accuse me of making a strawman and then
proceed to comment things ignoring all what I said on previous messages.

I'm not going to rehash the same arguments forever, so consider this
discussion over.

[snip]

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Chong Yidong]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> No, it does not.  It Just Works for the developer who uses it, but it
> encourages a personal workflow that some other developers would rather
> not see in the output of bzr log.
>
> Cf. Andreas's posts.

VC can now handle changesets, and has been able to for some time now.

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > 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

This encourages antisocial practices like per-file commits, and
committing ChangeLog separate from the changes.  Cf. the OP's
description of his workflow.  It gets in the way of use of Bazaar
features like "bzr log -n#" for other developers.  That is a problem,
if Emacs chooses to see it that way.

If Emacs has no intention of improving its common workflow, then it's
not a problem.  But if that's going to happen, there should be
discussion of whether folks like the OP (who is in good company with
the likes of rms and eliz) should be asked to invest the effort in a
forward-compatible workflow now, or if Emacs should wait to make such
improvements until the old-style workers are good and ready to accept
such changes (presumably due to retirement<wink>, since it will be
just as hard later as it is now, so they'll resist it then, too).

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Óscar Fuentes writes:
>
>  > 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
>
> This encourages antisocial practices like per-file commits, and
> committing ChangeLog separate from the changes.

It doesn't encourage certain antisocial practices, just makes them
possible. This is easily solvable by monitoring the commits ml and
sending polite mails to those committers that do not follow good
practices, listing them. I volunteer to do that. The Emacs VC history
already contains thousands of revisions consisting on separate commits
for the same change. A few more is no problem.

>  Cf. the OP's
> description of his workflow.  It gets in the way of use of Bazaar
> features like "bzr log -n#" for other developers.

Uh? What's the benefit of log -n# for one-revision merges?

> That is a problem, if Emacs chooses to see it that way.
>
> If Emacs has no intention of improving its common workflow, then it's
> not a problem.  But if that's going to happen, there should be
> discussion of whether folks like the OP (who is in good company with
> the likes of rms and eliz) should be asked to invest the effort in a
> forward-compatible workflow now, or if Emacs should wait to make such
> improvements until the old-style workers are good and ready to accept
> such changes (presumably due to retirement<wink>, since it will be
> just as hard later as it is now, so they'll resist it then, too).

Well, there is no reason to settle on one Golden Workflow. It is clear
that we want to introduce new good practices on how the VC history is
developed (one changeset per purpose, etc) but that practices are not
incompatible with multiple workflows. The feature branches workflow is
great for substantial changes, but a PITA for one-liners. The
centralized workflow is perfectly okay (unless you abuse it, or course,
but you can abuse the distributed one: what stops you from mixing
unrelated changes on the same merge?)

Since long time ago I think that the main problem most people here have
with the transition to bazaar is that they lack an insight on what a
DVCS is (and some even have no previous experience with changeset-based
VCSs!) People can understand the centralized usage of bzr without too
much effort, but pushing some hackers here to blindly use the
distributed workflow is asking for problems. A gradual introduction with
a simpler workflow helps in several ways. That's a personal decission,
no other is affected by it.

Please lets not forget that this is not about making Emacs a model of
orthodoxy in DVCS usage. It's about giving hackers a tool that helps
them to contribute to Emacs.

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > >  Cf. the OP's
 > > description of his workflow.  It gets in the way of use of Bazaar
 > > features like "bzr log -n#" for other developers.
 > 
 > Uh? What's the benefit of log -n# for one-revision merges?

You didn't read the OP's description of how that ChangeLog got
committed, obviously.  Please do that.

 > Well, there is no reason to settle on one Golden Workflow. It is clear
 > that we want to introduce new good practices on how the VC history is
 > developed (one changeset per purpose, etc) but that practices are not
 > incompatible with multiple workflows.

That's not at all my point.  The point is that there is a single
public repository that everybody is aiming at, and that personal
workflows that use centralization features *necessarily* impose that
personal workflow's history on the rest of the project.

 > distributed workflow is asking for problems. A gradual introduction with
 > a simpler workflow helps in several ways. That's a personal decission,
 > no other is affected by it.

You are wrong, at least in Bazaar which supports lightweight checkouts
and bound branches.  As soon as you bind a branch, you are at risk of
polluting the public history with personal mistakes.  Your convenience
may conflict with what is considered good practice by other developers.

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Óscar Fuentes writes:
>
>  > >  Cf. the OP's
>  > > description of his workflow.  It gets in the way of use of Bazaar
>  > > features like "bzr log -n#" for other developers.
>  > 
>  > Uh? What's the benefit of log -n# for one-revision merges?
>
> You didn't read the OP's description of how that ChangeLog got
> committed, obviously.  Please do that.

The OP is trying to follow your recommended workflow, getting very
confused and creating the problem. If he were using the centralized
workflow, the only advice he would need is "include all modified files
on the same commit" and `-log -n#' would be as informative (but less
verbose) as with the distributed workflow.

>  > Well, there is no reason to settle on one Golden Workflow. It is clear
>  > that we want to introduce new good practices on how the VC history is
>  > developed (one changeset per purpose, etc) but that practices are not
>  > incompatible with multiple workflows.
>
> That's not at all my point.  The point is that there is a single
> public repository that everybody is aiming at, and that personal
> workflows that use centralization features *necessarily* impose that
> personal workflow's history on the rest of the project.

No. No for one-commit changes. Nobody is recommending to use `push' here.

>  > distributed workflow is asking for problems. A gradual introduction with
>  > a simpler workflow helps in several ways. That's a personal decission,
>  > no other is affected by it.
>
> You are wrong, at least in Bazaar which supports lightweight checkouts
> and bound branches.  As soon as you bind a branch, you are at risk of
> polluting the public history with personal mistakes.  Your convenience
> may conflict with what is considered good practice by other developers.

Which are those personal mistakes? Committing something you didn't
intend to? People here are accustomed to check the changes before
committing. They were using CVS for 16 years, you know.

And how is that different from merging changes you didn't intend to send
upstream, like debug or untested code?

It would help a lot to the discussion if instead of saying "this is
problematic" the actual problems were described.

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > > You didn't read the OP's description of how that ChangeLog got
 > > committed, obviously.  Please do that.
 > 
 > The OP is trying to follow your recommended workflow, getting very
 > confused and creating the problem.

I do not think that is the case.  You still haven't seen the issue.
Mr. Handa said that he made about five commits (one for each
individual file including the ChangeLog) where best practice is to
have one commit for that kind of change.  Andreas at least finds that
undesirable.

 > If he were using the centralized workflow, the only advice he would
 > need is "include all modified files on the same commit"

Wrong.  He would have run into the same problem because vc.el (his
preferred VCS manager) is still file-oriented.  That is where his
confusion is coming from: the tools he wants to use (vc and bzr) are
mismatched.  Getting vc to do the right thing is going to require more
than just advice.

 > No. No for one-commit changes. Nobody is recommending to use `push' here.

Sure, but the people who are having problems with the workflow
recommended in BzrForEmacsDevs also clearly have "multiple commit"
workflows.  *They are going to have problems adjusting to the
one-commit style.*  That is not a problem with BzrForEmacsDevs, that
is a difference between current Emacs practice and what is generally
considered "best practice" (ie, pretty useful to a lot of people, not
an actual "optimum").

 > > You are wrong, at least in Bazaar which supports lightweight checkouts
 > > and bound branches.  As soon as you bind a branch, you are at risk of
 > > polluting the public history with personal mistakes.  Your convenience
 > > may conflict with what is considered good practice by other developers.
 > 
 > Which are those personal mistakes? Committing something you didn't
 > intend to?

Yes.  Rather unlikely, but you insist that there's *zero* problem, and
that's simply wrong.  Also, working with a tool you're not familiar
with, you're likely to make mistakes.

But more important than that is the second point.  With a good tool
*other* developers will want to use features like filtering change
records with "bzr log" that just weren't very usable with CVS.  So
practices like multiple commits per change are going to start to
become an annoyance to others where they were not in the CVS world
(because people grepped the ChangeLog file).

 > It would help a lot to the discussion if instead of saying "this is
 > problematic" the actual problems were described.

There are no big problems.  So you'll say to each one "that's not
really a problem" just as you did above.  There are enough little ones
that it is my judgment that we should discourage variant workflows,
*especially* combining them in one person's personal workflow, until
most of the core developers have the basics down.

Even you insist on a two-branch flow, not working in the trunk
mirror.  That is one of the most important inconveniences from
Mr. Handa's point of view, one which he really wants to go away.  He
wants each local commit to the the end of it.  The variants you
propose don't really address his issue as far as I can see.

Also, if he wants to continue using the multiple commit workflow, with
the BzrForEmacsDevs workflow, he can!  That is, he uses multiple
commits in his local (quickfixes) workspace, then a single merge to
the mirror, commit there, and it will appear as a single commit to
people using the default "bzr log".  This is a reasonable compromise
for most people, I think.

Re: GNU Emacs is on Bazaar now.

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> Wrong.  He would have run into the same problem because vc.el (his
> preferred VCS manager) is still file-oriented.  That is where his
> confusion is coming from: the tools he wants to use (vc and bzr) are
> mismatched.  Getting vc to do the right thing is going to require more
> than just advice.

It kinda does the right thing already (well for some backends, dunno
about bzr), if you use vc-dir to do your operations.

-Miles

-- 
Twice, adv. Once too often.

Re: GNU Emacs is on Bazaar now.

[Dan Nicolaescu]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

  > Óscar Fuentes writes:
  > 
  >  > > You didn't read the OP's description of how that ChangeLog got
  >  > > committed, obviously.  Please do that.
  >  > 
  >  > The OP is trying to follow your recommended workflow, getting very
  >  > confused and creating the problem.
  > 
  > I do not think that is the case.  You still haven't seen the issue.
  > Mr. Handa said that he made about five commits (one for each
  > individual file including the ChangeLog) where best practice is to
  > have one commit for that kind of change.  Andreas at least finds that
  > undesirable.
  > 
  >  > If he were using the centralized workflow, the only advice he would
  >  > need is "include all modified files on the same commit"
  > 
  > Wrong.  He would have run into the same problem because vc.el (his
  > preferred VCS manager) is still file-oriented.  

Have you actually checked what the current vc.el in Emacs can do?
Please do before making such statements.

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Dan Nicolaescu writes:

 > Have you actually checked what the current vc.el in Emacs can do?

No.  I can't look at Emacs code until XEmacs converts its license, and
using Emacs drives me nuts because of muscle memory.

 > Please do before making such statements.

I think that would be a bad idea.  For that reasons above I'm not in a
position to do checking effectively, but it's better that I embarrass
myself by being wrong (which is happy for Handa-san, who now should
know about all the tools needed for a reasonable "upgrade" for his
current CVS workflow to bzr) than to leave it entirely unmentioned.

Thank you for the work on vc.

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>  > The OP is trying to follow your recommended workflow, getting very
>  > confused and creating the problem.
>
> I do not think that is the case.  You still haven't seen the issue.
> Mr. Handa said that he made about five commits (one for each
> individual file including the ChangeLog) where best practice is to
> have one commit for that kind of change.  Andreas at least finds that
> undesirable.

Me too, and it is something that the OP should avoid. But his other
complain (having to write the commit message twice: one for the commit
and the other for the merge) is a different matter.

>  > If he were using the centralized workflow, the only advice he would
>  > need is "include all modified files on the same commit"
>
> Wrong.  He would have run into the same problem because vc.el (his
> preferred VCS manager) is still file-oriented.  That is where his
> confusion is coming from: the tools he wants to use (vc and bzr) are
> mismatched.  Getting vc to do the right thing is going to require more
> than just advice.

You can mark several files on a vc-dir buffer and bzr will commit them
all together. Its what I do all the time. No issues. You can do that
even from a regular `dir' buffer, AFAIK.

Maybe you are not aware that VC went through a complete rewrite to
support this on the last year or two.

>  > No. No for one-commit changes. Nobody is recommending to use `push' here.
>
> Sure, but the people who are having problems with the workflow
> recommended in BzrForEmacsDevs also clearly have "multiple commit"
> workflows.  *They are going to have problems adjusting to the
> one-commit style.*  That is not a problem with BzrForEmacsDevs, that
> is a difference between current Emacs practice and what is generally
> considered "best practice" (ie, pretty useful to a lot of people, not
> an actual "optimum").

Maybe this point should be emphasized on BzrForEmacsDevs. Maybe it
already is.

>  > > You are wrong, at least in Bazaar which supports lightweight checkouts
>  > > and bound branches.  As soon as you bind a branch, you are at risk of
>  > > polluting the public history with personal mistakes.  Your convenience
>  > > may conflict with what is considered good practice by other developers.
>  > 
>  > Which are those personal mistakes? Committing something you didn't
>  > intend to?
>
> Yes.  Rather unlikely, but you insist that there's *zero* problem, and
> that's simply wrong.

Read again. I'm not saying that there's zero problem. I'm saying that
people will need time to adapt, and the damage that they will do until
them will be irrelevant when put on top of 16 years of CVS history.

I already said that mistakes will be made whatever the workflow you
use. People is accustomed to double check their changes before
committing. So far, Emacs is not having serious problems because too
much people committed wrong things to the CVS repo. I don't think that
switching to bzr will make people irresponsible overnight.

> Also, working with a tool you're not familiar with, you're likely to
> make mistakes.

Yes. Working with a workflow that you do not understand makes mistakes
more probable, too.

[snip]

>  > It would help a lot to the discussion if instead of saying "this is
>  > problematic" the actual problems were described.
>
> There are no big problems.  So you'll say to each one "that's not
> really a problem" just as you did above.

Please do not misrepresent my position. One thing is saying that a few
more cases of multiple commits is not a problem after years of doing it,
other thing is saying that it is fine to keep doing it.

> There are enough little ones that it is my judgment that we should
> discourage variant workflows, *especially* combining them in one
> person's personal workflow, until most of the core developers have the
> basics down.
>
> Even you insist on a two-branch flow, not working in the trunk
> mirror.  That is one of the most important inconveniences from
> Mr. Handa's point of view, one which he really wants to go away.

And he can. Just setup another branch bounded with upstream and work
from it.

> He wants each local commit to the the end of it.  The variants you
> propose don't really address his issue as far as I can see.

My variant saves him to repeat part of the nasty work of merging and
reproducing the commit message.

> Also, if he wants to continue using the multiple commit workflow, with
> the BzrForEmacsDevs workflow, he can!  That is, he uses multiple
> commits in his local (quickfixes) workspace, then a single merge to
> the mirror, commit there, and it will appear as a single commit to
> people using the default "bzr log".  This is a reasonable compromise
> for most people, I think.

I don't think so. It does not save unnecessary work, which is the
problem the OP has.

What should be made clear is:

1. Commit all involved files together.

2. Put on the commit message exactly the same text you put on the
ChangeLog. I think there is something in VC for doing that
automatically, and if not it can be easily done.

This is much faster than committing each file separately. If they are
not scared away from directly committing upstream small changes instead
of having to go through the burden of merging and committing through the
local mirror, with the added side effect of being able to do everything
from within Emacs, they will be even happier.

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> 2. Put on the commit message exactly the same text you put on the
> ChangeLog.

That's not really necessary I think, tho it may be convenient.

-Miles

-- 
Sabbath, n. A weekly festival having its origin in the fact that God made the
world in six days and was arrested on the seventh.

Re: GNU Emacs is on Bazaar now.

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > Maybe you are not aware that VC went through a complete rewrite to
 > support this on the last year or two.

What I am or am not aware of is irrelevant.  What matters is that it
would be a change for Handa-san.  A change that nobody has yet advised
him to make!

 > Read again. I'm not saying that there's zero problem.

OK.  You made a comment about "perfectly OK", which I read as
including "perfectly safe."  Sorry.

 > Please do not misrepresent my position. One thing is saying that a few
 > more cases of multiple commits is not a problem after years of doing it,
 > other thing is saying that it is fine to keep doing it.

You're missing the point that until now people didn't use "cvs log" in
preference to "grep ChangeLog", etc, though.  Now they are going to
want to.

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Óscar Fuentes writes:
>
>  > Maybe you are not aware that VC went through a complete rewrite to
>  > support this on the last year or two.
>
> What I am or am not aware of is irrelevant.  What matters is that it
> would be a change for Handa-san.  A change that nobody has yet advised
> him to make!

It is advertised on BzrQuickStartForEmacsDevs

>  > Read again. I'm not saying that there's zero problem.
>
> OK.  You made a comment about "perfectly OK", which I read as
> including "perfectly safe."  Sorry.

You are taking that expression out of context.

>  > Please do not misrepresent my position. One thing is saying that a few
>  > more cases of multiple commits is not a problem after years of doing it,
>  > other thing is saying that it is fine to keep doing it.
>
> You're missing the point that until now people didn't use "cvs log" in
> preference to "grep ChangeLog", etc, though.  Now they are going to
> want to.

I hope so.

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Karl Fogel]

Óscar Fuentes <ofv@wanadoo.es> writes:
>Well, there is no reason to settle on one Golden Workflow. It is clear
>that we want to introduce new good practices on how the VC history is
>developed (one changeset per purpose, etc) but that practices are not
>incompatible with multiple workflows. The feature branches workflow is
>great for substantial changes, but a PITA for one-liners. The
>centralized workflow is perfectly okay (unless you abuse it, or course,
>but you can abuse the distributed one: what stops you from mixing
>unrelated changes on the same merge?)
>
>Since long time ago I think that the main problem most people here have
>with the transition to bazaar is that they lack an insight on what a
>DVCS is (and some even have no previous experience with changeset-based
>VCSs!) People can understand the centralized usage of bzr without too
>much effort, but pushing some hackers here to blindly use the
>distributed workflow is asking for problems. A gradual introduction with
>a simpler workflow helps in several ways. That's a personal decission,
>no other is affected by it.
>
>Please lets not forget that this is not about making Emacs a model of
>orthodoxy in DVCS usage. It's about giving hackers a tool that helps
>them to contribute to Emacs.

Sure, I think everyone agrees on that.

So if people made their one-line changes this way:

  $ cd ${EMACS_DEV_AREA}/trunk
  $ bzr pull
  $ <<< make one-line obvious typo fix, edit ChangeLog file too >>>
  $ bzr commit -m "* README: Fix silly typo."
  <<< change automatically sent from local bound trunk to upstream trunk >>>
  $ 

would there be any negative consequences?  It violates the "keep local
trunk as pristine as possible" rule, and people will run into
complexities if upstream diverges from local trunk before their commit
is ready (they'd have to revert, re-pull, and redo, or something like
that).  Those are the reasons we didn't recommend it in the doc.  But
aside from those problems, could there be any negative consequences to
the versioned history?  I think not, but would like more knowledgeable
people to comment.

-Karl

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

Karl Fogel <kfogel@red-bean.com> writes:

> So if people made their one-line changes this way:
>
>   $ cd ${EMACS_DEV_AREA}/trunk
>   $ bzr pull
>   $ <<< make one-line obvious typo fix, edit ChangeLog file too >>>
>   $ bzr commit -m "* README: Fix silly typo."
>   <<< change automatically sent from local bound trunk to upstream trunk >>>
>   $ 
>
> would there be any negative consequences?  It violates the "keep local
> trunk as pristine as possible" rule, and people will run into
> complexities if upstream diverges from local trunk before their commit
> is ready (they'd have to revert, re-pull, and redo, or something like
> that).

Please note that I'm not recommending to use the local mirror as a
quickfix area. I prefer to have a separate quickfix branch bound to
upstream. With that setup, the hack-commit cycle is almost identical to
CVS or Subversion, with the only difference being that an `update' is
often required before the `commit'.

(As you know, on a bound branch you do not `pull', you `update'. No need
to revert if upstream diverged, because `update' merges upstream's
changes into your edited files, as CVS does. That `pull' works on a
bound branch was discussed some days ago on the bzr ml after a question
by Juanma and IIRC the conclusion was that it is accidental.)

> Those are the reasons we didn't recommend it in the doc.  But aside
> from those problems, could there be any negative consequences to the
> versioned history?  I think not, but would like more knowledgeable
> people to comment.

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Eli Zaretskii]

> From: Karl Fogel <karl.fogel@canonical.com>
> Date: Sun, 27 Dec 2009 17:55:43 -0500
> 
> In case you missed it: GNU Emacs is on Bazaar now.  Please see
> http://www.emacswiki.org/emacs/BzrForEmacsDevs for how to (re)obtain
> your development sources from Bazaar.

So what's the plan regarding Emacs 24?  Will there be soon such a
branch (or a branch for Emacs 23, leaving the trunk for Emacs 24), or
not just yet?  Should I maintain the bidi code as my local branch for
the time being?

Re: GNU Emacs is on Bazaar now.

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Should I maintain the bidi code as my local branch for the time being?

There is no reason to keep development branches private.

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: GNU Emacs is on Bazaar now.

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 28 Dec 2009 21:00:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Should I maintain the bidi code as my local branch for the time being?
> 
> There is no reason to keep development branches private.

I would like a formal go-ahead from Stefan and Yidong, before I make a
public branch.  They had something in mind last time we talked about
this.

Re: GNU Emacs is on Bazaar now.

[James Cloos]

On a 64-bit box (Linux kernel, GNU userland) the initial branch caused
the python process to boloon to over two gigs of vm, most kept resident.

One'll need a big box to work with the new repo.

I can imagine that it'll be a significant load on the server, too.

Too bad bzr is written in python.

How painful is it to grab an additional branch from the main repo over
sftp, comared to the grab of trunk?  Ie, did the initial branch grab
just the history of trunk, or di it grab the hsitory of all of the
branches?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

James Cloos <cloos@jhcloos.com> writes:

> On a 64-bit box (Linux kernel, GNU userland) the initial branch caused
> the python process to boloon to over two gigs of vm, most kept resident.

What version are you using? For me, it required approx 1 GB on a 64 bit
GNU/Linux machine. (bzr 2.0.1, python 2.6.4, http)

> One'll need a big box to work with the new repo.

You need lots of memory for the initial branch. For the rest of
operations, I think you need much less memory. Branching from the local
trunk mirror required ~180 MB for me, using a shared repository.

> I can imagine that it'll be a significant load on the server, too.

With http/sftp, bazaar transfers a lot of data but as it is CPU-bound
too, it does not hit the server too hard. The bzr protocol (or bzr+ssh)
causes a noticeable cpu load on the server.

> Too bad bzr is written in python.
>
> How painful is it to grab an additional branch from the main repo over
> sftp, comared to the grab of trunk?  Ie, did the initial branch grab
> just the history of trunk, or di it grab the hsitory of all of the
> branches?

Grabbing and additional branch requires a fraction of the cost of the
initial branch. Bzr will transfer only the missing revisions. IIRC it
required 22 minutes for the initial branch (trunk) and 4 minutes for
multi-tty.

-- 
Óscar

Re: GNU Emacs is on Bazaar now.

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Tue, 29 Dec 2009 20:40:47 +0100
> 
> James Cloos <cloos@jhcloos.com> writes:
> 
> > On a 64-bit box (Linux kernel, GNU userland) the initial branch caused
> > the python process to boloon to over two gigs of vm, most kept resident.
> 
> What version are you using? For me, it required approx 1 GB on a 64 bit
> GNU/Linux machine. (bzr 2.0.1, python 2.6.4, http)

I didn't measure, but didn't see any problems that would hint the box
was thrashing.

> > How painful is it to grab an additional branch from the main repo over
> > sftp, comared to the grab of trunk?  Ie, did the initial branch grab
> > just the history of trunk, or di it grab the hsitory of all of the
> > branches?
> 
> Grabbing and additional branch requires a fraction of the cost of the
> initial branch. Bzr will transfer only the missing revisions. IIRC it
> required 22 minutes for the initial branch (trunk) and 4 minutes for
> multi-tty.

It was 15 minutes and less than 1, respectively, for me.

Re: GNU Emacs is on Bazaar now.

[James Cloos]

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

JimC> On a 64-bit box (Linux kernel, GNU userland) the initial branch caused
JimC> the python process to boloon to over two gigs of vm, most kept resident.

Óscar> What version are you using? For me, it required approx 1 GB on a 64 bit
Óscar> GNU/Linux machine. (bzr 2.0.1, python 2.6.4, http)

That one still has an old install of bzr: 2.0rc1.  Python just tells my 2.6.

I'll have to update that one, but I will not try downloading a new
branch; neither side needs to waste the required bandwidth.

Óscar> Branching from the local trunk mirror required ~180 MB for me,
Óscar> using a shared repository.

Agreed; creating a quickfix branch as per the wiki required much less vm.

>> I can imagine that it'll be a significant load on the server, too.

Óscar> With http/sftp, bazaar transfers a lot of data but as it is CPU-bound
Óscar> too, it does not hit the server too hard. The bzr protocol (or bzr+ssh)
Óscar> causes a noticeable cpu load on the server.

I was thinking of vm load, but that was dumb, since bzr obviously does
not run on the server in sftp/http mode.... [SIGH]

Is the VM load an issue in ssh mode, along with the cpu load?

>> How painful is it to grab an additional branch from the main repo over
>> sftp, comared to the grab of trunk?

Óscar> Grabbing and additional branch requires a fraction of the cost of the
Óscar> initial branch. Bzr will transfer only the missing revisions. IIRC it
Óscar> required 22 minutes for the initial branch (trunk) and 4 minutes for
Óscar> multi-tty.

Good.  That is what I hoped for.

I do see that it transfers much more data than it ends up storing on
disk.  A du(1) of .bzr trunk/.bzr is on the order of 200 Megs, but
it (claims to) transfer(s) something like twice that over teh sftp link.

And my first pull since the initial branch only changed 27 files (25 M,
1 +N and 1 -D), created a new pack of 1417748 octets, but needed 5 Megs
of xfer to grab those changes.

I expect that the native protocol is more efficient.


Also, given the note about locking, does creating a branch over sftp
create the kind of lock that was described earlier?  Or does that only
occur when /pushing/ changes to the sv repo?  I used sftp instead of
http even though I am read-only because my last attempt over http
couldn't even max out a DS0 straw, much less a fat pipe.  But I'd hate
to block commiters by doing so.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

James Cloos <cloos@jhcloos.com> writes:

[snip]

>>> I can imagine that it'll be a significant load on the server, too.
>
> Óscar> With http/sftp, bazaar transfers a lot of data but as it is CPU-bound
> Óscar> too, it does not hit the server too hard. The bzr protocol (or bzr+ssh)
> Óscar> causes a noticeable cpu load on the server.
>
> I was thinking of vm load, but that was dumb, since bzr obviously does
> not run on the server in sftp/http mode.... [SIGH]
>
> Is the VM load an issue in ssh mode, along with the cpu load?

The cpu load on the server is only an issue for the bzr[+ssh]
protocol. I don't know how much VM load the bzr smart server causes
while serving a remote branch operation, but it is worth testing.

>>> How painful is it to grab an additional branch from the main repo over
>>> sftp, comared to the grab of trunk?
>
> Óscar> Grabbing and additional branch requires a fraction of the cost of the
> Óscar> initial branch. Bzr will transfer only the missing revisions. IIRC it
> Óscar> required 22 minutes for the initial branch (trunk) and 4 minutes for
> Óscar> multi-tty.
>
> Good.  That is what I hoped for.
>
> I do see that it transfers much more data than it ends up storing on
> disk.  A du(1) of .bzr trunk/.bzr is on the order of 200 Megs, but
> it (claims to) transfer(s) something like twice that over teh sftp link.
>
> And my first pull since the initial branch only changed 27 files (25 M,
> 1 +N and 1 -D), created a new pack of 1417748 octets, but needed 5 Megs
> of xfer to grab those changes.

Over the sftp/http protocols, bzr acts very dumb. It needs to read
lots of data for knowing which revisions to grab, etc.

> I expect that the native protocol is more efficient.

The bzr protocol does lots of work that otherwise the client must do if
it were using the dumb protocols, so it is significantly more efficient.

> Also, given the note about locking, does creating a branch over sftp
> create the kind of lock that was described earlier?  Or does that only
> occur when /pushing/ changes to the sv repo?  I used sftp instead of
> http even though I am read-only because my last attempt over http
> couldn't even max out a DS0 straw, much less a fat pipe.  But I'd hate
> to block commiters by doing so.

IIRC someone here said that bazaar supports concurrent r/w access over
http/sftp, which is quite surprising to me as adding info to the history
can touch a big area of the metadata, AFAIK. The report about the lock
issue seems to confirm that bazaar locks the branch (or repository?)
sometimes. I don't know for which operations bazaar locks and if it
locks only writes or reads too.


-- 
Óscar