Re: GNU Emacs is on Bazaar now.

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

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