Re: GNU Emacs is on Bazaar now.

["Stephen J. Turnbull" <stephen@xemacs.org>]

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