Re: GNU Emacs is on Bazaar now.

["Óscar Fuentes" <ofv@wanadoo.es>]

"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