Workflow to accumulate individual changes?

Workflow to accumulate individual changes?

[Juanma Barranquero]

Let's suppose I want to create a local post-23.2 branch where I do
want to commit small changes to install on the trunk post-release. I
don't want to be forced to create a task branch for every one of them,
because they are small changes, and a new branch implies having to
bootstrap[1] anew. So I'd like to accumulate the changes into a single
branch.

Once the trunk is open again, what would be the procedure to install
the changes? Obviously not "bzr merge ../post-23.2", because that
would create a single [merge] commit. Will I be forced to repeat "bzr
log" and "bzr merge --revision=REVID ../post-23.2" for each change?
That seems a bit cumbersome. Is there any way to simplify it? Perhaps
a plugin?

    Juanma

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Wed, Dec 30, 2009 at 22:34, Juanma Barranquero <lekktu@gmail.com> wrote:

> bootstrap[1] anew. So I'd like to accumulate the changes into a single

I forgot the note, so:

[1] What does people do to create new branches and not having to do a
full bootstrap? A recursive copy of all *.o and *.elc files in the
parent branch? I know there's a plugin that helps with git-style
colocated branches, but I'm asking about using normal branches.

    Juanma

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> Let's suppose I want to create a local post-23.2 branch where I do
> want to commit small changes to install on the trunk post-release. I
> don't want to be forced to create a task branch for every one of them,
> because they are small changes, and a new branch implies having to
> bootstrap[1] anew. So I'd like to accumulate the changes into a single
> branch.
>
> Once the trunk is open again, what would be the procedure to install
> the changes? Obviously not "bzr merge ../post-23.2", because that
> would create a single [merge] commit. Will I be forced to repeat "bzr
> log" and "bzr merge --revision=REVID ../post-23.2" for each change?
> That seems a bit cumbersome. Is there any way to simplify it? Perhaps
> a plugin?

*IF* they are small changes, i.e., the sort of things that you would do
on the quickfixes branch, *AND* if you didn't merge with trunk, this
should work keeping the history nice:

<hack>
bzr commit
<hack>
bzr commit
...
<when post-release arrives>:
bzr rebase
bzr push

The resulting history on upstream will be linear, as if you committed
each change one by one on top of the previous one.

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Wed, Dec 30, 2009 at 22:46, Óscar Fuentes <ofv@wanadoo.es> wrote:

> *IF* they are small changes, i.e., the sort of things that you would do
> on the quickfixes branch, *AND* if you didn't merge with trunk, this
> should work keeping the history nice:
>
> <hack>
> bzr commit
> <hack>
> bzr commit
> ...
> <when post-release arrives>:
> bzr rebase
> bzr push
>
> The resulting history on upstream will be linear, as if you committed
> each change one by one on top of the previous one.

If my post-23.2 branch is branched from my local trunk mirror, will
"bzr push" push to it? Will that work when trunk is a bound branch? Or
are you suggesting branching post-23.2 from
bzr.savannah.gnu.org/srv/bzr/emacs/trunk?

Anyway, after thinking about the issue, I'm not sure it'd work,
because of ChangeLog.

  cd emacs
  branch trunk post-23.2
  cd post-23.2
  # hack hack hack, including editing ChangeLog
  # days pass
  # 23.2 released
  cd ../trunk
  bzr update
  cd ../post-23.2
  bzr rebase
  bzr push     # ugh
  # dates in ChangeLog are wrong, so you need an additional commit to
fix the ChangeLog entries

so it only really works for fixes that do not need ChangeLog entries.

    Juanma

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Wed, Dec 30, 2009 at 22:46, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> *IF* they are small changes, i.e., the sort of things that you would do
>> on the quickfixes branch, *AND* if you didn't merge with trunk, this
>> should work keeping the history nice:
>>
>> <hack>
>> bzr commit
>> <hack>
>> bzr commit
>> ...
>> <when post-release arrives>:
>> bzr rebase
>> bzr push
>>
>> The resulting history on upstream will be linear, as if you committed
>> each change one by one on top of the previous one.
>
> If my post-23.2 branch is branched from my local trunk mirror, will
> "bzr push" push to it?

You can provide a location:

bzr rebase URL
bzr push URL

> Will that work when trunk is a bound branch?

I do not recommend using your local mirror for that.

> Or are you suggesting branching post-23.2 from
> bzr.savannah.gnu.org/srv/bzr/emacs/trunk?

No, you can branch from your local mirror if you wish (and why
not?). Remember that a branch is an autonomous identity that can
communicate with any other branch.

> Anyway, after thinking about the issue, I'm not sure it'd work,
> because of ChangeLog.

[snip]

> so it only really works for fixes that do not need ChangeLog entries.

Yup. This requires editing before sending upstream, so the most you can
do is to use a bzr branch as a patch depot.

Other option for having a patch depot is to use `bzr shelve', then when
you can commit unshelve each change separately, edit Changelog, commit
it... It seems as feature abuse to me, but it can be manageable if the
amount of changes is small and don't overlap.

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 01:21, Óscar Fuentes <ofv@wanadoo.es> wrote:

> You can provide a location:
>
> bzr rebase URL
> bzr push URL
[...]
> No, you can branch from your local mirror if you wish (and why
> not?). Remember that a branch is an autonomous identity that can
> communicate with any other branch.

I understand that. I though you were saying that "bzr push" (without
URL) would work in this case.

> Yup. This requires editing before sending upstream, so the most you can
> do is to use a bzr branch as a patch depot.

Yes, I see :(  Well, it's still better than having to branch for each
small change.

    Juanma

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> Anyway, after thinking about the issue, I'm not sure it'd work,
> because of ChangeLog.

[snip]

>   # dates in ChangeLog are wrong, so you need an additional commit to
> fix the ChangeLog entries
>
> so it only really works for fixes that do not need ChangeLog entries.

Thinking a bit more about this...

`rebase' stops if it finds conflicts, then you need to resolve the
conflicts (i.e. edit the conflicted changes) and continue the rebase.

If somehow the rebase finds a conflict on the ChangeLog for every
rebased revision, you could fix the dates. I know by experience that
Subversion generates a conflict every time two changes append lines to a
file. If bzr generates a conflict when two changes happen at the top of
the ChangeLog file, you could arrange things for this to happen: the
first revision should conflict right away; for the second revision to
conflict, you'll need to leave the top of the ChangeLog on a way that it
can't merge the second revision, etc.

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 02:04, Óscar Fuentes <ofv@wanadoo.es> wrote:

> If somehow the rebase finds a conflict on the ChangeLog for every
> rebased revision, you could fix the dates. I know by experience that
> Subversion generates a conflict every time two changes append lines to a
> file. If bzr generates a conflict when two changes happen at the top of
> the ChangeLog file, you could arrange things for this to happen: the
> first revision should conflict right away; for the second revision to
> conflict, you'll need to leave the top of the ChangeLog on a way that it
> can't merge the second revision, etc.

I'd rather have Bazaar not to generate a conflict for changes at the
top of the file; it's common enough, and I've had my share of them on
CVS :-)

That said, what you propose could work, but of course it's quite
hackish. Let's hope someday the rebase plugin will grow an option to
rebase interactively, stopping before the commit.

    Juanma

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

>> If somehow the rebase finds a conflict on the ChangeLog for every
>> rebased revision, you could fix the dates. I know by experience that
>> Subversion generates a conflict every time two changes append lines to a
>> file. If bzr generates a conflict when two changes happen at the top of
>> the ChangeLog file, you could arrange things for this to happen: the
>> first revision should conflict right away; for the second revision to
>> conflict, you'll need to leave the top of the ChangeLog on a way that it
>> can't merge the second revision, etc.
>
> I'd rather have Bazaar not to generate a conflict for changes at the
> top of the file; it's common enough, and I've had my share of them on
> CVS :-)
>
> That said, what you propose could work, but of course it's quite
> hackish.

It works and yes, it is hackish :-) Just make sure that after every
conflict resolve the first line of the ChangeLog differs from the first
line of the next revision.

> Let's hope someday the rebase plugin will grow an option to
> rebase interactively, stopping before the commit.

There is a big chance that adding that feature is very easy, and plugins
are not under the very strict development policy of Bazaar, so submit a
feature request to the plugin tracker:

https://launchpad.net/bzr-rewrite

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 02:48, Óscar Fuentes <ofv@wanadoo.es> wrote:

> It works and yes, it is hackish :-) Just make sure that after every
> conflict resolve the first line of the ChangeLog differs from the first
> line of the next revision.

Well, I'll give it a try. Thanks for looking into it.

> so submit a
> feature request to the plugin tracker:
>
> https://launchpad.net/bzr-rewrite

Will do right now.

    Juanma

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 31 Dec 2009 02:33:39 +0100
> Cc: emacs-devel@gnu.org
> 
> That said, what you propose could work, but of course it's quite
> hackish. Let's hope someday the rebase plugin will grow an option to
> rebase interactively, stopping before the commit.

Except that most experts on bzr I've read say rebasing is the wrong
way to go[1].  So I think we should not flee to that corner so easily,
upon bumping on the first problematic issue.

ChangeLog files will present a problem for feature branches and
quick-fix branches alike.  Though an annoyance, I don't see how it is
a problem significant enough to recommend rebase as the main vehicle
of routine work, given the downside of rebasing (rewriting history
etc.).

Am I missing something?

---------------
[1] http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 05:21, Eli Zaretskii <eliz@gnu.org> wrote:

> Except that most experts on bzr I've read say rebasing is the wrong
> way to go[1].

Personally, and with all due respect, I don't consider this: "There
are many theoretical objections to rebasing, and I won’t rehash them
here. There’s general consensus that rebasing is sort of icky." as a
sort of expert opinion, just biased. People used to git's rebase find
it extremely useful. And, in fact, this other bit:

> “Why isn’t rebase support in core?” Rebase support is currently packaged
> as a plugin. This plugin is widely distributed, even in the standard Mac OS
> X installation bundle.

isn't exactly true anymore, as it is also included at least in the
standard Windows standalone installation.

> So I think we should not flee to that corner so easily,
> upon bumping on the first problematic issue.

We're not fleeing into any corner. Weren't I thinking that ChangeLog
present problems that should be discussed, I wouldn't have brought the
issue.

> ChangeLog files will present a problem for feature branches and
> quick-fix branches alike.  Though an annoyance, I don't see how it is
> a problem significant enough to recommend rebase as the main vehicle
> of routine work, given the downside of rebasing (rewriting history
> etc.).
>
> Am I missing something?

Yes. Neither of us is "recommending rebase as the main vehicle of
routine work". I was talking very specifically of a workflow I intend
to use, but I have no idea how common it'll be for other people; and
for my use, an interactive rebase would be a perfect option. I
wouldn't dream of suggest Karl to discuss rebase on BzrForEmacsDevs,
for example.

    Juanma

Re: Workflow to accumulate individual changes?

[Miles Bader]

Juanma Barranquero <lekktu@gmail.com> writes:
>> Except that most experts on bzr I've read say rebasing is the wrong
>> way to go[1].
>
> Personally, and with all due respect, I don't consider this: "There
> are many theoretical objections to rebasing, and I won’t rehash them
> here. There’s general consensus that rebasing is sort of icky." as a
> sort of expert opinion, just biased. People used to git's rebase find
> it extremely useful.

Yup.  Rebasing rocks, especially interactive rebasing.

To be honest, a huge amount of bzr docs and commentary seems to be
essentially bzr apologia trying to compensate for technical failings in
bzr by saying "ok, so bzr doesn't do that as well as the competition,
but you didn't really want to do that anyway... trust us..."

-Miles

-- 
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like.  Otherwise the
programs they write will be pretty weird.  -- Donald Knuth

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Reply-To: Miles Bader <miles@gnu.org>
> System-Type: x86_64-unknown-linux-gnu
> Date: Thu, 31 Dec 2009 14:12:15 +0900
> 
> To be honest, a huge amount of bzr docs and commentary seems to be
> essentially bzr apologia trying to compensate for technical failings in
> bzr by saying "ok, so bzr doesn't do that as well as the competition,
> but you didn't really want to do that anyway... trust us..."

Except that not only the documentation says that, the most active bzr
developers say that as well.  Maybe you know enough about bzr to
decide that it's FUD or cheap marketing, but I'm willing to try the
recommended way first, before I decide otherwise based on problems I
bump into (if and when).

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

From: Eli Zaretskii <eliz@gnu.org>
To: Juanma Barranquero <lekktu@gmail.com>
CC: ofv@wanadoo.es, emacs-devel@gnu.org
In-reply-to: <f7ccd24b0912302036y51436f47p164fe640f926cfb7@mail.gmail.com>
	(message from Juanma Barranquero on Thu, 31 Dec 2009 05:36:30 +0100)
Subject: Re: Workflow to accumulate individual changes?
Reply-to: Eli Zaretskii <eliz@gnu.org>
References: <f7ccd24b0912301334u6df4cf24k7625713ba8e4252@mail.gmail.com> 
	<87fx6sm8yl.fsf@telefonica.net> <f7ccd24b0912301557s7e40ab26h8ee88c630757c1ce@mail.gmail.com> 
	<873a2slzrr.fsf@telefonica.net> <f7ccd24b0912301733k510c6bbaub97223dcf2565055@mail.gmail.com> 
	<83ws03db8v.fsf@gnu.org> <f7ccd24b0912302036y51436f47p164fe640f926cfb7@mail.gmail.com>
--text follows this line--
> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 31 Dec 2009 05:36:30 +0100
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> Personally, and with all due respect, I don't consider this: "There
> are many theoretical objections to rebasing, and I won’t rehash them
> here. There’s general consensus that rebasing is sort of icky." as a
> sort of expert opinion, just biased.

Me neither.  I'm talking about the rest of the reasons, which _are_
described in detail.

> People used to git's rebase find it extremely useful.

I don't know anything about git, so I cannot talk about this.  Just
remember that Stephen pointed to a posting by Linus who very
eloquently explained how rebasing is a bad idea in at least one
situation.

> Weren't I thinking that ChangeLog present problems that should be
> discussed, I wouldn't have brought the issue.

If ChangeLog maintenance is such a big problem, I think we should
resolve it here and now.  Otherwise, it's a tail wagging the dog.

> > ChangeLog files will present a problem for feature branches and
> > quick-fix branches alike.  Though an annoyance, I don't see how it is
> > a problem significant enough to recommend rebase as the main vehicle
> > of routine work, given the downside of rebasing (rewriting history
> > etc.).
> >
> > Am I missing something?
> 
> Yes. Neither of us is "recommending rebase as the main vehicle of
> routine work". I was talking very specifically of a workflow I intend
> to use, but I have no idea how common it'll be for other people; and
> for my use, an interactive rebase would be a perfect option. I
> wouldn't dream of suggest Karl to discuss rebase on BzrForEmacsDevs,
> for example.

ChangeLog's are part of everyone's workflow (unless we decide to stop
using them).  If we think ChangeLog's are causing significant
inconveniences that are not addressed in the recommended workflow, and
if rebasing is the recommended solution for that, then we had better
address these issues now, and by all means mention them on the wiki.

IOW, what annoys Juanma Barranquero, will probably annoy a few more,
so I would not dismiss that as Juanma's private problems whose
solution concerns no one but Juanma ;-)

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 11:44, Eli Zaretskii <eliz@gnu.org> wrote:

> Me neither.  I'm talking about the rest of the reasons, which _are_
> described in detail.

Please! The document does not show real arguments against rebase, just
"questions about the necessity of rebasing in typical workflows", from
the perspective of people who do not have or like rebase. For the
opposite perspective, just look for a few happy git users.

> I don't know anything about git, so I cannot talk about this.  Just
> remember that Stephen pointed to a posting by Linus who very
> eloquently explained how rebasing is a bad idea in at least one
> situation.

Of course. Every user of rebase knows that: you shouldn't rebase a
public branch (and even that is OK in cases where the users know that
rebasing will be done). But here we were discussing *private*
rebasing.

> If ChangeLog maintenance is such a big problem, I think we should
> resolve it here and now.  Otherwise, it's a tail wagging the dog.

Not a big problem, a small but repeated inconvencience.

> IOW, what annoys Juanma Barranquero, will probably annoy a few more,
> so I would not dismiss that as Juanma's private problems whose
> solution concerns no one but Juanma ;-)

Well, I can agree with that if you can agree that perhaps rebase
*could be* the best fix after all... ;-)

    Juanma

Re: Workflow to accumulate individual changes?

[Karl Fogel]

Juanma Barranquero <lekktu@gmail.com> writes:
>> IOW, what annoys Juanma Barranquero, will probably annoy a few more,
>> so I would not dismiss that as Juanma's private problems whose
>> solution concerns no one but Juanma ;-)
>
>Well, I can agree with that if you can agree that perhaps rebase
>*could be* the best fix after all... ;-)

I've never used 'bzr rebase', and have no competency to evaluate the
arguments either way here, but... wouldn't something would smell fishy
if rebase were part of our regular workflow?  That somehow seems wrong.

If we find we're about to recommend that, please ask on the Bazaar list
first (maybe you have already).

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Thu, 31 Dec 2009 14:44:51 -0500
> 
> I've never used 'bzr rebase', and have no competency to evaluate the
> arguments either way here, but... wouldn't something would smell fishy
> if rebase were part of our regular workflow?  That somehow seems wrong.

I originally thought this was the case, but I was mistaken; see
Óscar's message just now.  It is for a situation that hopefully will
not happen too often for too many.

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 20:44, Karl Fogel <kfogel@red-bean.com> wrote:

> I've never used 'bzr rebase', and have no competency to evaluate the
> arguments either way here, but... wouldn't something would smell fishy
> if rebase were part of our regular workflow?

Only if you have a priori bias that rebase smells funny.

But anyhow, I don't think anyone is proposing rebase as part of the
regular workflow. I wasn't.

    Juanma

Re: Workflow to accumulate individual changes?

[Richard Stallman]

    I've never used 'bzr rebase', and have no competency to evaluate the
    arguments either way here, but... wouldn't something would smell fishy
    if rebase were part of our regular workflow?  That somehow seems wrong.

Are you saying that hackers who rebase can get addicted? ;-).

Re: Workflow to accumulate individual changes?

[Stephen J. Turnbull]

Richard Stallman writes:

 >     I've never used 'bzr rebase', and have no competency to evaluate the
 >     arguments either way here, but... wouldn't something would smell fishy
 >     if rebase were part of our regular workflow?  That somehow seems wrong.
 > 
 > Are you saying that hackers who rebase can get addicted? ;-).

There's plenty of examples!

Re: Workflow to accumulate individual changes?

[Stephen J. Turnbull]

Karl Fogel writes:
 > Juanma Barranquero <lekktu@gmail.com> writes:

 > >Well, I can agree with that if you can agree that perhaps rebase
 > >*could be* the best fix after all... ;-)
 > 
 > I've never used 'bzr rebase', and have no competency to evaluate the
 > arguments either way here, but... wouldn't something would smell fishy
 > if rebase were part of our regular workflow?  That somehow seems wrong.

No, it's a matter of style.  Let me summarize:

1.  Everybody agrees that rebasing a branch which is not 100% private
    is problematic.

2.  Some people like rebasing private branches before pushing them,
    basically because it makes the history more linear.  (git people
    generally do.)  Making the history more linear often makes
    bisection more effective, because (except for the initial graft)
    the patches tend to be smaller and localize the defect better.

3.  Some people dislike rebasing private branches, because it makes
    the history more linear.  (bzr people generally do.)  There are
    two reasons typically given:

    a.  Work done concurrently is "misrepresented" as being
        sequential.  I suspect these people generally have an
        intuition of b, but don't express it that way.

    b.  It's easy to think that all commits have properly tested
        because all commits on each (original) branch and the tip have
        been tested, but that is false.  In fact, all commits between
        the graft point and the tip need to be retested.  Of course,
        "need" is assuming a "test every commit" discipline.

    There's a reason that is not typically given, too.

    c.  In some DVCSes, rebase destroys history.  It is in general not
        possible to recover the original branch from a rebase given
        only the "after" DAG.  In bzr a rebase makes recovering the
        original branch a task for someone familiar with the
        internals.  (It may even be impossible in some cases, I don't
        know enough about the internals to say.)

If it's not obvious, let me state that I am biased toward the
pro-rebase side.  But that's a matter of taste.

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> That said, what you propose could work, but of course it's quite
>> hackish. Let's hope someday the rebase plugin will grow an option to
>> rebase interactively, stopping before the commit.
>
> Except that most experts on bzr I've read say rebasing is the wrong
> way to go[1].

It often is. In *this* case it is not wrong nor right. It is just what
does the job. Please note the big IFs in my answer to Juanma.

> So I think we should not flee to that corner so easily, upon bumping
> on the first problematic issue.

Agreed. If anyone thinks that rebase it the solution for his problem,
please ask here first.

> ChangeLog files will present a problem for feature branches and
> quick-fix branches alike.

Very true. On Juanma's case, if he accumulated a signicant number of
small changes, rebasing can save quite a bit of work compared to
creating a patch, applying it, re-writing a commit message and commit
for each change. Or merging one change, edit the ChangeLog, write the
commit message, commit and repeat for the next change (which possibly is
the most orthodox solution and recommendable if the amount of changes is
moderate.)

> Though an annoyance, I don't see how it is a problem significant
> enough to recommend rebase as the main vehicle of routine work, given
> the downside of rebasing (rewriting history etc.).

The history is rewritten at Juanma's end. For the rest of users, the
final result is indistinguishable of the case where Juanma commits a
series of small changes on a fast sequence.

> Am I missing something?

Yes. That `goto' is evil but sometimes it has its uses :-)

I concede that rebase here can be questionable as the most efficient or
dumb-proof solution (you have to be very careful or the whole process
can be ruined and repeated; it is strongly advised to backup your branch
first.)

The ChangeLog is a big incovenience for working locally while upstream
access is restricted. I hope that after some time, people will
experience the fact that a ChangeLog is completely redundant on a
changeset-based VCS.

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: =?utf-8?Q?=C3=93scar_Fuentes?= <ofv@wanadoo.es>
> Date: Thu, 31 Dec 2009 06:06:51 +0100
> 
> > ChangeLog files will present a problem for feature branches and
> > quick-fix branches alike.
> 
> Very true. On Juanma's case, if he accumulated a signicant number of
> small changes, rebasing can save quite a bit of work compared to
> creating a patch, applying it, re-writing a commit message and commit
> for each change. Or merging one change, edit the ChangeLog, write the
> commit message, commit and repeat for the next change (which possibly is
> the most orthodox solution and recommendable if the amount of changes is
> moderate.)

It's an annoyance, yes, but not a large one.  After all, you have
everything right there in the same Emacs session.  How hard is it to
reorder a few log entries?

> > Though an annoyance, I don't see how it is a problem significant
> > enough to recommend rebase as the main vehicle of routine work, given
> > the downside of rebasing (rewriting history etc.).
> 
> The history is rewritten at Juanma's end. For the rest of users, the
> final result is indistinguishable of the case where Juanma commits a
> series of small changes on a fast sequence.

Unless I misunderstood what I've read, that's not accurate: the final
result _will_ matter for others, if and when those others will want at
some point in the future to dig into Juanma's changes and understand
how the final code came into existence -- which parts of it were
written by Juanma, which ones by others, and which ones are result of
bzr merges.  In fact, Juanma himself may wish to do this kind of
archeology some time after committing.

> The ChangeLog is a big incovenience for working locally while upstream
> access is restricted.

In my work on bidi Emacs, I keep a separate ChangeLog file precisely
for that reason.  With CVS, it was simply an unversioned file.  With
bzr, I will probably have it committed to my local branch, but will
delete it after copying (some of) its contents to the upstream logs
when the feature is merged with upstream.  If someone has a better
idea for a long-term feature branch, I'm all ears.

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 11:26, Eli Zaretskii <eliz@gnu.org> wrote:

> Unless I misunderstood what I've read, that's not accurate: the final
> result _will_ matter for others, if and when those others will want at
> some point in the future to dig into Juanma's changes and understand
> how the final code came into existence -- which parts of it were
> written by Juanma, which ones by others, and which ones are result of
> bzr merges.  In fact, Juanma himself may wish to do this kind of
> archeology some time after committing.

No. We're discussing small patches, every one of them a single commit,
all of them unrelated. Once I push the changes, the past is
irrelevant. My using a private branch and rebase would be utterly
indistinguishable of my having developed and committed each one on the
trunk/ (as some are suggesting for such quickfixes).

rebase is a tool to keep private history private, and public history
clean. Nothing more, nothing less.

    Juanma

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Thu, 31 Dec 2009 06:06:51 +0100
> 
> If anyone thinks that rebase it the solution for his problem, please
> ask here first.

So what problem was it in this case, for which rebase is a solution?
Is it the case of a number of small unrelated changes that somehow
accumulated in the local branch?  Or is it something else?

It cannot be a single coherent change, because for that, we still
think the workflow described on the wiki for the quickfixes branch is
the recommended way to go, right?

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> If anyone thinks that rebase it the solution for his problem, please
>> ask here first.
>
> So what problem was it in this case, for which rebase is a solution?

It was considered as a hack for editing the ChangeLog dates of old local
commits before sending them upstream.

> Is it the case of a number of small unrelated changes that somehow
> accumulated in the local branch?

Yes, it is about sending upstream a series of small changes that you
accumulated on a branch (because you had no net access of because
commits to upstream were temporarily restricted for whatever reason.)

There are two problems with this: first, merging the ChangeLog entries
correctly (mainly updating dates) and second, not having to merge and
commit all those changes one by one.

If you agree that the quickfixes->merge-to-trunk->commit workflow is the
right thing, you don't need rebase here: you have to merge and commit to
upstream each change individually and you can edit the ChangeLog at that
point.

If you think that having to merge a small change is an unnecessary
burden and prefer to commit directly to upstream, rebase is the solution
but the ChangeLog is on the way forcing you to resort to a hack for
editing it. If it no were ChangeLog, sending upstream that series of
small changes would need just two commands (rebase & push).

The general issue here is the impact the ChangeLog has on off-line
working, including into the concept of off-line feature branches that
live for more than a day.

[snip]

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 19:27, Eli Zaretskii <eliz@gnu.org> wrote:

> So what problem was it in this case, for which rebase is a solution?
> Is it the case of a number of small unrelated changes that somehow
> accumulated in the local branch?

Yes. Not that "somehow accumulate", but that I want to accumulate,
because I don't want to have to branch (and bootstrap) ten times for
ten different small patches that cannot be committed before the
release.

FWIW, I *don't* have currently ten such commits, just one or two; but
I'm not very inclined to branch just to remember to change "(defun
xxx-mode () ...)" to "(define-derived-mode xxx-mode ...)" in a few
weeks/months.

    Juanma

Re: Workflow to accumulate individual changes?

[Stephen J. Turnbull]

Juanma Barranquero writes:

 >   bzr push     # ugh
 >   # dates in ChangeLog are wrong, so you need an additional commit to
 > fix the ChangeLog entries
 > 
 > so it only really works for fixes that do not need ChangeLog entries.

Why are the dates in the ChangeLog wrong?  The commit history is in
"bzr log", the work history is in the ChangeLog.  What's the problem
with that?  Does Emacs have a policy that ChangeLog dates must
correspond to the commit sequence or some such?

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 01 Jan 2010 22:53:20 +0900
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Does Emacs have a policy that ChangeLog dates must correspond to the
> commit sequence or some such?

Yes.

Re: Workflow to accumulate individual changes?

[Giorgos Keramidas]

On Wed, 30 Dec 2009 22:34:07 +0100, Juanma Barranquero <lekktu@gmail.com> wrote:
> Let's suppose I want to create a local post-23.2 branch where I do
> want to commit small changes to install on the trunk post-release. I
> don't want to be forced to create a task branch for every one of them,
> because they are small changes, and a new branch implies having to
> bootstrap[1] anew. So I'd like to accumulate the changes into a single
> branch.
>
> Once the trunk is open again, what would be the procedure to install
> the changes? Obviously not "bzr merge ../post-23.2", because that
> would create a single [merge] commit. Will I be forced to repeat "bzr
> log" and "bzr merge --revision=REVID ../post-23.2" for each change?
> That seems a bit cumbersome. Is there any way to simplify it? Perhaps
> a plugin?

Hi Juanma,

If the changes are separate commits, it *may* be simple to avoid a
gazillion merges (one for each small change) by using the rebase plugin
of bazaar.  This way instead of having a history like

      [1]         [2]         [3]
     /           /           /
    o --- o --- o --- o --- o --- o

with 'o' revisions being trunk commits and local changes [1], [2] and
[3] forking from several different ancestor changesets, you can keep
your changes in a local branch like this

    o --- o --- o --- o --- o --- o --- [1] --- [2] --- [3]

Every time you "bzr pull" from the trunk, you can re-rebase your local
changesets on top of the new trunk.

Without rebase, you would have to merge each one of [1], [2] and [3]
separately, resulting in a final history similar to:

      [1] ----------------------------.
     /                                 \
    o --- o --- o --- o --- o --- o --- [m1] --- [m2] --- [m3]
                 \           \                  /         /
                  [2]         [3] ------------ / --------'
                    \                         /
                     `-----------------------'

with one merge changeset for each local patch.  This is a moderately
complex history graph, that is mostly readable for three local changes,
but things quickly get messy with, say, upwards of 20 local patches.

The mostly linear history of rebased changesets is easier to read for
local patches.  At least it is for me.

The good thing about keeping a local set of patches rebased to the
latest version of turnk is that you can start developing the patches
with revision N of the trunk:

    o --- o --- [N] --- [1] --- [2]

then you cal pull as many times as necessary from the trunk (pull
revisions marked with '*' below:

    o --- o --- [N] --- o --- * --- o --- o --- * --- [1] --- [2]

and keep the local patches rebased until they are 'done'.  When they are
ready for trunk, you can simply "bzr push" them and stop rebasing the
local patches.  They are not part of trunk and everyone will see them.

The down-sides of rebasing that I know of are:

  (1) You cannot publish the rebased changesets and then rebase them
      again.  People who pulled the `old' rebase will still have it in
      their local branch and you cannot do anything to delete *their*
      local changes.

  (2) Rebasing modifies the history but does not necessarily leave any
      trace of the old state of the branch.  So if you discover that you
      botched the rebase or one of the merges that happened *during* the
      rebase, you are screwed.  Keeping a backup copy of the local
      branch *before* a rebase operation (e.g. a tarball) is always a
      good idea.

  (3) Rebasing in a bound branch is probably a bad idea.  I am not sure
      how well the plugin will work with changes that are already pushed
      to the remote side of a bound branch.  It is very likely that it
      will create a very messed up branch state both in the local and
      the remote side of the world.

Having said that I've previously posted a, admittedly rather minimal,
example of instructions for the installation and the commands of the
bzr-rebase plugin at
<http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00871.html>.
It may be worth expanding on this if you think it would help you keep a
set of local-only patches until they are ready for the public trunk.

HTH,
Giorgos

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Wed, Dec 30, 2009 at 23:54, Giorgos Keramidas
<keramida@ceid.upatras.gr> wrote:

> If the changes are separate commits, it *may* be simple to avoid a
> gazillion merges (one for each small change) by using the rebase plugin
> of bazaar.  This way instead of having a history like

Yes, thanks to both Óscar and you for the idea. Unfortunately, as I've
said, I think it does not mess too well with ChangeLog.

BTW, I'm interested in ways to deal with ChangeLog issues like this.
For example, if you spend a while developing a large side project on a
branch, your ChangeLog in that branch will reflect the dates of
individual changes. In the past, at the moment of merging the branch
back into the trunk, the dates were changed (most of unicode-2, or
multi-tty, were entered into the ChangeLog at the date the merge
happened). With Bazaar, we'd like to keep that kind of operation as a
single merge, so perhaps the last commit in the task branch will need
to be a ChangeLog fix with the day the merging is planned... Works,
but seems a bit messy.

I know it has been decided we still will maintain ChangeLogs, and I'm
not going to discuss it, but it's a bit of a pity, when a good commit
message policy and bzr log --gnu-changelog could save us the trouble.

    Juanma

Re: Workflow to accumulate individual changes?

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

> I know it has been decided we still will maintain ChangeLogs, and I'm
> not going to discuss it, but it's a bit of a pity, when a good commit
> message policy and bzr log --gnu-changelog could save us the trouble.

ChangeLog entries and commit messages serve a different purpose.
ChangeLog entries describe the "physical" changes, a commit message the
"logical" change.  That is, the commit message describes the changeset
on a higher level than the ChangeLog entries.  As such it does not make
sense to repeat the ChangeLog entries in the commit message.

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: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Thu, 31 Dec 2009 10:21:05 +0100
> Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> ChangeLog entries and commit messages serve a different purpose.
> ChangeLog entries describe the "physical" changes, a commit message the
> "logical" change.  That is, the commit message describes the changeset
> on a higher level than the ChangeLog entries.  As such it does not make
> sense to repeat the ChangeLog entries in the commit message.

I agree with the principle (and I think most, if not all, of others do
as well).  But what does this mean in practice?  Are you suggesting
that the commit message should not mention the changes in individual
files at all, just the general idea?

If that's not what you suggest, i.e. if changes in individual files
_should_ be mentioned, it will be very hard to resist the temptation
of copying the ChangeLog entries, perhaps _in_addition_to_ the
high-level description that we already asked to provide, a couple of
weeks ago.

Re: Workflow to accumulate individual changes?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Are you suggesting that the commit message should not mention the
> changes in individual files at all, just the general idea?

Yes, that's what they are for.  Just like a merge commit does not repeat
the history of all merged revisions, but just summerizes it.

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: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: lekktu@gmail.com,  keramida@ceid.upatras.gr,  emacs-devel@gnu.org
> Date: Thu, 31 Dec 2009 12:44:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Are you suggesting that the commit message should not mention the
> > changes in individual files at all, just the general idea?
> 
> Yes, that's what they are for.

But then the corresponding ChangeLog entries should have the text
identical or very similar to the commit message in front of them, or
else have some other means of locating the log entries easily.

Anyway, I'm okay with this policy, if Stefan and Yidong approve it.

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 13:23, Eli Zaretskii <eliz@gnu.org> wrote:

> Anyway, I'm okay with this policy, if Stefan and Yidong approve it.

I'm not, unless Stefan and Yidong force it.

    Juanma

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 31 Dec 2009 13:38:16 +0100
> Cc: Andreas Schwab <schwab@linux-m68k.org>, keramida@ceid.upatras.gr, emacs-devel@gnu.org
> 
> On Thu, Dec 31, 2009 at 13:23, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Anyway, I'm okay with this policy, if Stefan and Yidong approve it.
> 
> I'm not, unless Stefan and Yidong force it.

Please tell why not, perhaps I'll change my mind ;-)

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 14:25, Eli Zaretskii <eliz@gnu.org> wrote:

> Please tell why not, perhaps I'll change my mind ;-)

It's already been said it, I think. Theoretically, ChangeLog is for
"physical" changes, and the commit log is for "logical" changes, as
Andreas pointed out. But that is difficult to enforce; so in order to
understand a given change, you already have to look at both (and,
sometimes, you *need* both to understand what's happened). It's better
IMO to put all relevant info together, even if that means duplicating
it. And that will ease the switch to a ChangeLog-less future, if and
when we someday decide that it is not really useful to maintain the
ChangeLogs anymore.

    Juanma

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 31 Dec 2009 14:37:21 +0100
> Cc: schwab@linux-m68k.org, keramida@ceid.upatras.gr, emacs-devel@gnu.org
> 
> It's better IMO to put all relevant info together, even if that
> means duplicating it.

I don't mind that, either.

Re: Workflow to accumulate individual changes?

[Giorgos Keramidas]

On Thu, 31 Dec 2009 07:23:28 -0500, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: lekktu@gmail.com,  keramida@ceid.upatras.gr,  emacs-devel@gnu.org
>> Date: Thu, 31 Dec 2009 12:44:46 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Are you suggesting that the commit message should not mention the
>> > changes in individual files at all, just the general idea?
>>
>> Yes, that's what they are for.
>
> But then the corresponding ChangeLog entries should have the text
> identical or very similar to the commit message in front of them, or
> else have some other means of locating the log entries easily.
>
> Anyway, I'm okay with this policy, if Stefan and Yidong approve it.

I think it's very useful to see file changes in the ChangeLog.  It helps
a lot when an Emacs user downloads a tarball of the sources from the FTP
site, because file changes are visible without full access to the
original branch itself or access to a bzr client.

Maybe we can try to strike a balance between not keeping the ChangeLog
up to date at all and making it difficult to commit *one* changeset that
includes both ChangeLog updates _and_ file updates by committing the
ChangeLog updates separately?  This way, we can have a very short
summary in the ChangeLog commit, e.g.:

: keramida@kobe:/tmp/bzrdemo$ cat ChangeLog
: 2009-12-31  Giorgos Keramidas  <keramida@ceid.upatras.gr>
:
:         * foo: Add a new 'foo' file.
:
: keramida@kobe:/tmp/bzrdemo$ bzr log --show-ids
: ------------------------------------------------------------
: revno: 2
: revision-id: keramida@ceid.upatras.gr-20091231133847-f7og1ku98r1ng019
: parent: keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1
: committer: Giorgos Keramidas <keramida@ceid.upatras.gr>
: branch nick: bzrdemo
: timestamp: Thu 2009-12-31 15:38:47 +0200
: message:
:   ChangeLog for keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1
: ------------------------------------------------------------
: revno: 1
: revision-id: keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1
: committer: Giorgos Keramidas <keramida@ceid.upatras.gr>
: branch nick: bzrdemo
: timestamp: Thu 2009-12-31 15:36:56 +0200
: message:
:   Add a new 'foo' file.
:
: keramida@kobe:/tmp/bzrdemo$

To avoid doubling the revisions we keep in the repository, by following
*every* single commit with a ChangeLog update, we can batch ChangeLog
updates.  So a developer can work in his own local branch and commit
several local changes before updating the ChangeLog.  Then a single
ChangeLog commit on top of those can be stacked on top of the batch of
local changes, right before they are pushed to the trunk.

In a related side-node, it seems vc-update-change-log doesn't grok bzr
branches.  What are the missing bits?  Can we add them now that Emacs
itself uses bzr?

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 14:43, Giorgos Keramidas
<keramida@ceid.upatras.gr> wrote:

> I think it's very useful to see file changes in the ChangeLog.  It helps
> a lot when an Emacs user downloads a tarball of the sources from the FTP
> site, because file changes are visible without full access to the
> original branch itself or access to a bzr client.

If we were using the commit log to put ChangeLog entries, the
ChangeLog could be reconstructed as part of making the release tarball
by a simple

  bzr log --gnu-changelog -r ...

> Maybe we can try to strike a balance between not keeping the ChangeLog
> up to date at all and making it difficult to commit *one* changeset that
> includes both ChangeLog updates _and_ file updates by committing the
> ChangeLog updates separately?

That breaks the idea that commits should try to respect the ACID
(atomicity, consistency, isolation, durability) principle.

> To avoid doubling the revisions we keep in the repository, by following
> *every* single commit with a ChangeLog update, we can batch ChangeLog
> updates.  So a developer can work in his own local branch and commit
> several local changes before updating the ChangeLog.  Then a single
> ChangeLog commit on top of those can be stacked on top of the batch of
> local changes, right before they are pushed to the trunk.

Personally, I find this idea ugly.

    Juanma

Re: Workflow to accumulate individual changes?

[Alfred M. Szmidt]

A major problem with generating the ChangeLog from the commit messages
is that you cannot fix a incorrect entry.  More often than not, you
need to do fixes (forgotten entries, incorrect formating, ...).

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 15:07, Alfred M. Szmidt <ams@gnu.org> wrote:

> A major problem with generating the ChangeLog from the commit messages
> is that you cannot fix a incorrect entry.  More often than not, you
> need to do fixes (forgotten entries, incorrect formating, ...).

I know, I've done quite a few changes to old ChangeLog entries :-)

Still, that seems to me a lesser problem that having to check two
places to get all relevant info. And, if you look deep at our
ChangeLogs, after years and years of use I'm sure you wouldn't take
more than half an hour to find some mistake (I'm not talking about
typos, but missing, wrong or duplicate entries, etc.). At the end of
the day, you look at the ChangeLog or the commit message to get an
idea of what happened; if you need the full info, there's the diffs.

    Juanma

Re: Workflow to accumulate individual changes?

[Alfred M. Szmidt]

   Still, that seems to me a lesser problem that having to check two
   places to get all relevant info. And, if you look deep at our
   ChangeLogs, after years and years of use I'm sure you wouldn't take
   more than half an hour to find some mistake (I'm not talking about
   typos, but missing, wrong or duplicate entries, etc.).

That may be true, but it is not a argument to make it impossible to
fix incorrect entries.  Having proper entries is good for developers,
and for copyright reasons.

Re: Workflow to accumulate individual changes?

[David Kastrup]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    Still, that seems to me a lesser problem that having to check two
>    places to get all relevant info. And, if you look deep at our
>    ChangeLogs, after years and years of use I'm sure you wouldn't take
>    more than half an hour to find some mistake (I'm not talking about
>    typos, but missing, wrong or duplicate entries, etc.).
>
> That may be true, but it is not a argument to make it impossible to
> fix incorrect entries.  Having proper entries is good for developers,
> and for copyright reasons.

I don't see what "copyright reasons" would make it a good idea to let a
commit+message done by A be silently (or non-silently) be changed by B
at a later date.

-- 
David Kastrup

Re: Workflow to accumulate individual changes?

[Richard Stallman]

    A major problem with generating the ChangeLog from the commit messages
    is that you cannot fix a incorrect entry.

Is there no way to fix an error in a commit message?

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

> Is there no way to fix an error in a commit message?

You can undo a commit with `bzr uncommit'. However, this only makes
sense if you are committing to some of your local branches. Once you
send your change upstream, pretending to alter the revision is like
asking for the removal of a message you published on a mailing list,
because the history is replicated everywhere.

Because of this and other more tehcnical reasons, NEVER use `bzr
uncommit' against an upstream branch. You would only cause lots of
misery.

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 01 Jan 2010 05:03:57 +0100
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > Is there no way to fix an error in a commit message?
> 
> You can undo a commit with `bzr uncommit'.

But the issue is not to undo the commit, only fix the text of the
commit message.  Something similar to "cvs admin -mREV:MESSAGE".

Typos in commit messages still can happen, even with bzr ;-)

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Is there no way to fix an error in a commit message?
>> 
>> You can undo a commit with `bzr uncommit'.
>
> But the issue is not to undo the commit, only fix the text of the
> commit message.  Something similar to "cvs admin -mREV:MESSAGE".

There is no equivalent for `cvs admin -mREV' in bazaar.

Maybe it is not clear from my description that `bzr uncommit' does not
throw away the change: it reverses the state to the point previous to
the commit, so you do

bzr uncommit
bzr commit -m "the right message here"

> Typos in commit messages still can happen, even with bzr ;-)

AFAIK, the commit message is a part of the revision, so if bazaar
allowed to simply edit it, you would be "transmuting" the revision,
(i.e. it would have a different revision-id) and that is absolutely
forbidden in DVCSs. What you can do is to remove some revisions and
replace them with others. Just don't do it on public branches.

You can change anything on the history of your private branch using a
variety of techniques (being `bzr uncommit' the simplest one,) but we
have to admit that changing the message of an arbitrary revision is
something that can't be done due to the nature of DVCSs

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Richard Stallman]

    You can change anything on the history of your private branch using a
    variety of techniques (being `bzr uncommit' the simplest one,) but we
    have to admit that changing the message of an arbitrary revision is
    something that can't be done due to the nature of DVCSs

How sad.

I wonder if we could provide a different feature which would
do the same job: namely, a way to enter a subsequent revision
which says, "This message replaces the commit message of revision N."
We could set it up so that the usual ways of looking at history
will do that edit, as if the commit message of revision N had been changed.
There would be an option to disable this automatic editing and show
things as they really are.

Re: Workflow to accumulate individual changes?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> But the issue is not to undo the commit, only fix the text of the
> commit message.

That's fundamentally the same.

> Something similar to "cvs admin -mREV:MESSAGE".

You have to forget the idea that you can modify (published) history.
With a DVCS you can only create history.  Once you have published a
commit it is immutable.

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: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: =?utf-8?Q?=C3=93scar?= Fuentes <ofv@wanadoo.es>,  emacs-devel@gnu.org
> Date: Fri, 01 Jan 2010 13:19:14 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But the issue is not to undo the commit, only fix the text of the
> > commit message.
> 
> That's fundamentally the same.

Perhaps in bzr it is, but not in real life.

> > Something similar to "cvs admin -mREV:MESSAGE".
> 
> You have to forget the idea that you can modify (published) history.
> With a DVCS you can only create history.  Once you have published a
> commit it is immutable.

A commit message is not history, it's a label of that history.

Re: Workflow to accumulate individual changes?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> A commit message is not history

It is an integral part of the 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: Workflow to accumulate individual changes?

[Karl Fogel]

Andreas Schwab <schwab@linux-m68k.org> writes:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>> A commit message is not history
>
>It is an integral part of the commit.

This is an old debate in the DVCS world.  The issue is that changes are
distributed and there is no "master copy" of a given change; instead,
there are many copies of the same change, and you can tell they're the
same because they all have the same unique id (and same contents).

In CVS, the master copy is always in the repository and there is exactly
one repository.  So if you want to read log messages, you do 'cvs log'
and it contacts the repository (or, in Emacs's case, 'cvs update' gets
updates to the ChangeLog files, but that also contacts the repository).

In Bzr, the savannah trunk branch is sort of the equivalent CVS's "the
repository"... but the changes in that branch are replicated among
hundreds or thousands of developers' local branches.  If you tweak a
commit message on the savannah branch, bzr has no mechanism for
conveying that tweak to the other branches, because the commit message
is considered part of the change, just like the diff.  Tweak the commit
message and you've tweaked the change -- it's no longer the same change.

There are other ways the system could work.  IIUC, in git the commit
message is *not* part of the change's identity, it's just attached to
the change, so you can edit the message later.  But I don't know if git
has a way of propagating those edits to other clones; nor do I know what
git would do if two different clones tweak a commit message for the
"same" change in two different ways and then one of them has to receive
the other's edits.  Is there conflict resolution on "out-of-band" data,
and if so, how would it work?

Perhaps the difficulty of that question is why bzr doesn't support this.

In any case, IMHO it is a minor feature regression that we can no longer
tweak log messages after the fact, but it's not a huge problem.

-Karl

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  ofv@wanadoo.es,  emacs-devel@gnu.org
> Date: Fri, 01 Jan 2010 14:18:00 -0500
> 
> If you tweak a commit message on the savannah branch, bzr has no
> mechanism for conveying that tweak to the other branches

Well, that's just it: bzr _should_ have such a mechanism.  I really
don't care if modifying a commit message would count as a new revision
of the tree, all I care is that "bzr log" and friends show the
modified commit message by default (if there would be a way to see the
original one before the fix, that's okay too).

> because the commit message
> is considered part of the change, just like the diff.  Tweak the commit
> message and you've tweaked the change -- it's no longer the same change.

There's no requirement to pretend the tree is the same after modifying
the commit message.  The requirement is that "bzr log" shows it with
the commit, that's all.

Re: Workflow to accumulate individual changes?

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> If you tweak a commit message on the savannah branch, bzr has no
>> mechanism for conveying that tweak to the other branches
>
> Well, that's just it: bzr _should_ have such a mechanism.  I really
> don't care if modifying a commit message would count as a new revision
> of the tree, all I care is that "bzr log" and friends show the
> modified commit message by default (if there would be a way to see the
> original one before the fix, that's okay too).

I think the problem is that this involves tracking changes to changes.
What if you want to change the change to the change?

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org
> Date: Fri, 01 Jan 2010 15:09:06 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> If you tweak a commit message on the savannah branch, bzr has no
> >> mechanism for conveying that tweak to the other branches
> >
> > Well, that's just it: bzr _should_ have such a mechanism.  I really
> > don't care if modifying a commit message would count as a new revision
> > of the tree, all I care is that "bzr log" and friends show the
> > modified commit message by default (if there would be a way to see the
> > original one before the fix, that's okay too).
> 
> I think the problem is that this involves tracking changes to changes.
> What if you want to change the change to the change?

Just add another revision.  It's the same as with versioned files,
really.

Re: Workflow to accumulate individual changes?

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Karl Fogel <kfogel@red-bean.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  ofv@wanadoo.es,  emacs-devel@gnu.org
>> Date: Fri, 01 Jan 2010 14:18:00 -0500
>> 
>> If you tweak a commit message on the savannah branch, bzr has no
>> mechanism for conveying that tweak to the other branches
>
>Well, that's just it: bzr _should_ have such a mechanism.  I really
>don't care if modifying a commit message would count as a new revision
>of the tree, all I care is that "bzr log" and friends show the
>modified commit message by default (if there would be a way to see the
>original one before the fix, that's okay too).

I agree it's a bug.  Having established that... the most productive
place to discuss Bazaar bugs is probably the Bazaar list.

-K

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 01 Jan 2010 15:13:00 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> From: Karl Fogel <kfogel@red-bean.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  ofv@wanadoo.es,  emacs-devel@gnu.org
> >> Date: Fri, 01 Jan 2010 14:18:00 -0500
> >> 
> >> If you tweak a commit message on the savannah branch, bzr has no
> >> mechanism for conveying that tweak to the other branches
> >
> >Well, that's just it: bzr _should_ have such a mechanism.  I really
> >don't care if modifying a commit message would count as a new revision
> >of the tree, all I care is that "bzr log" and friends show the
> >modified commit message by default (if there would be a way to see the
> >original one before the fix, that's okay too).
> 
> I agree it's a bug.  Having established that... the most productive
> place to discuss Bazaar bugs is probably the Bazaar list.

Done.

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> If you tweak a commit message on the savannah branch, bzr has no
>> mechanism for conveying that tweak to the other branches
>
> Well, that's just it: bzr _should_ have such a mechanism.  I really
> don't care if modifying a commit message would count as a new revision
> of the tree, all I care is that "bzr log" and friends show the
> modified commit message by default (if there would be a way to see the
> original one before the fix, that's okay too).

By replacing a revision with another revision, you are effectively
breaking the mirror branches on all sites that updated/pulled before the
"fix" (you make them diverge.) And that's the easier part. You will
cause lots of problems, really.

A mechanism that notices that certain revision replaces a previous one
and propagates the fact when two branches communicate, not only would be
very complex, but quite questionable from the ethical POV, as it could
be used to modify or destroy VC history by a malicious individual.

As for the commit message and other metadata such as the committer name
being part of the hashed data, it is considered a fundamental
requirement for keeping history integrity.

[snip]

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 01 Jan 2010 22:25:20 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> If you tweak a commit message on the savannah branch, bzr has no
> >> mechanism for conveying that tweak to the other branches
> >
> > Well, that's just it: bzr _should_ have such a mechanism.  I really
> > don't care if modifying a commit message would count as a new revision
> > of the tree, all I care is that "bzr log" and friends show the
> > modified commit message by default (if there would be a way to see the
> > original one before the fix, that's okay too).
> 
> By replacing a revision with another revision, you are effectively
> breaking the mirror branches on all sites that updated/pulled before the
> "fix" (you make them diverge.)

Who said anything about replacing a revision?  I was talking about
_adding_ a revision, if needed.  It just needs to be added in a
special way, such that nothing changes except the addition of a
modified commit message, and "bzr log" showing that modified message
instead of the original one.

Re: Workflow to accumulate individual changes?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Who said anything about replacing a revision?  I was talking about
> _adding_ a revision, if needed.  It just needs to be added in a
> special way, such that nothing changes except the addition of a
> modified commit message, and "bzr log" showing that modified message
> instead of the original one.

There needs to be a reference to this added information, otherwise
nobody will see it.

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: Workflow to accumulate individual changes?

[Teemu Likonen]

On 2010-01-01 14:18 (-0500), Karl Fogel wrote:

> IIUC, in git the commit message is *not* part of the change's
> identity, it's just attached to the change, so you can edit the
> message later.

That's wrong--or your "change's identity" means something I don't
understand. In Git commit's author, committer, date, parent commits'
SHA1s, referenced tree object's SHA1 and commit message together make
the content of a commit object. From this content is calculated the SHA1
of that commit object. If you change any of these the SHA1 of the commit
object will be different and hence the whole commit object will be
different (i.e. its identity is different).

So no, it's not possible to change commit message (or any information
the commit object contains) without making it a different commit.


There is a related feature, though. New Git versions have "git notes"
command which allows user to add additional notes to commits. Such extra
notes can be added and removed freely and "git log" prints them after
the commit message. Notes can be sent between repositories but currently
it doesn't happen automatically with usual pull/push commands.

http://www.kernel.org/pub/software/scm/git/docs/git-notes.html

Re: Workflow to accumulate individual changes?

[Karl Fogel]

Teemu Likonen <tlikonen@iki.fi> writes:
>On 2010-01-01 14:18 (-0500), Karl Fogel wrote:
>> IIUC, in git the commit message is *not* part of the change's
>> identity, it's just attached to the change, so you can edit the
>> message later.
>
>That's wrong--or your "change's identity" means something I don't
>understand. In Git commit's author, committer, date, parent commits'
>SHA1s, referenced tree object's SHA1 and commit message together make
>the content of a commit object. From this content is calculated the SHA1
>of that commit object. If you change any of these the SHA1 of the commit
>object will be different and hence the whole commit object will be
>different (i.e. its identity is different).

Someone -- whom I thought would know -- specifically told me that the
commit message is *not* part of the SHA1 of the commit object.  I double
checked, because this was surprising to me, and they confirmed.

But either they were wrong, or I misunderstood, or possibly both.  In
any case, I'm sorry for spreading misinformation.

>There is a related feature, though. New Git versions have "git notes"
>command which allows user to add additional notes to commits. Such extra
>notes can be added and removed freely and "git log" prints them after
>the commit message. Notes can be sent between repositories but currently
>it doesn't happen automatically with usual pull/push commands.
>
>http://www.kernel.org/pub/software/scm/git/docs/git-notes.html

Maybe this is what the person thought I was talking about.

-K

Re: Workflow to accumulate individual changes?

[Teemu Likonen]

On 2010-01-01 15:12 (-0500), Karl Fogel wrote:

> Someone -- whom I thought would know -- specifically told me that the
> commit message is *not* part of the SHA1 of the commit object. I
> double checked, because this was surprising to me, and they confirmed.
>
> But either they were wrong, or I misunderstood, or possibly both. In
> any case, I'm sorry for spreading misinformation.

No problem. I'll still repeat that it's indeed misinformation. Here's a
raw content of a certain commit object in Emacs Git repository (the
four-space indent is by me):

    $ git cat-file commit 9a339f5

    tree ef4fd5bd3689b5c17a3eb6df705564a5d4fed602
    parent 031c7e409992e98fefc98c3e8a6be981a00c55a9
    author Chong Yidong <cyd@stupidchicken.com> 1261901472 +0000
    committer Chong Yidong <cyd@stupidchicken.com> 1261901472 +0000

    * minibuf.c (Fall_completions): Minor optimization.

We can see the commit message in the end. "git log" prints it like this:

    $ git log -1 9a339f5

    commit 9a339f5040b089f97a4b5c86eefa3942b2e5eda4
    Author: Chong Yidong <cyd@stupidchicken.com>
    Date:   2009-12-27 08:11:12 +0000

        * minibuf.c (Fall_completions): Minor optimization.

Re: Workflow to accumulate individual changes?

[Stephen J. Turnbull]

Teemu Likonen writes:

 > No problem. I'll still repeat that it's indeed misinformation. Here's a
 > raw content of a certain commit object in Emacs Git repository (the
 > four-space indent is by me):

cat'ing the object doesn't prove anything.  The header content is
easily separable from the commit message, and in theory you could
generate the SHA1 based on the header only.  (I can't imagine Linus
doing such a thing, but it would immediately occur to most Emacs
hackers.)

Here's an experimental proof:

# Verify identity.
$ git rev-parse HEAD
f008c025d04f4bcec79f2bb463589461d95a3154
$ git cat-file commit HEAD | git hash-object --stdin -t commit
f008c025d04f4bcec79f2bb463589461d95a3154

# Verify difference -- I happen to know that the word "Update" occurs
# uniquely in the comment portion of this commit.
$ git cat-file commit HEAD | sed -e s/Update/Rewrite/ \
  | git hash-object --stdin -t commit
ff2c9790c738d10205086a12ce394069ceccbb83

Re: Workflow to accumulate individual changes?

[Karl Fogel]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>Teemu Likonen writes:
> > No problem. I'll still repeat that it's indeed misinformation. Here's a
> > raw content of a certain commit object in Emacs Git repository (the
> > four-space indent is by me):
>
>cat'ing the object doesn't prove anything.  The header content is
>easily separable from the commit message, and in theory you could
>generate the SHA1 based on the header only.  (I can't imagine Linus
>doing such a thing, but it would immediately occur to most Emacs
>hackers.)

Heh.  I followed up in private mail to Teemu saying the same thing.

>Here's an experimental proof:
>
># Verify identity.
>$ git rev-parse HEAD
>f008c025d04f4bcec79f2bb463589461d95a3154
>$ git cat-file commit HEAD | git hash-object --stdin -t commit
>f008c025d04f4bcec79f2bb463589461d95a3154
>
># Verify difference -- I happen to know that the word "Update" occurs
># uniquely in the comment portion of this commit.
>$ git cat-file commit HEAD | sed -e s/Update/Rewrite/ \
>  | git hash-object --stdin -t commit
>ff2c9790c738d10205086a12ce394069ceccbb83

Now *that's* the proof we needed.  Thanks.

It would be very winning if some DVCS would

  a) Allow tweaking commit messages
  b) Version those tweaks
  c) Propagate those tweaks to other branches whenever the other branch
     receives data from the tweaked branch
  d) Have a conflict resolution mechanism for when different tweaks collide

This is a tall order, however.  I'm not surprised no DVCS (AFAIK) does it.

-K

Re: Workflow to accumulate individual changes?

[Miles Bader]

Karl Fogel <kfogel@red-bean.com> writes:
> This is a tall order, however.  I'm not surprised no DVCS (AFAIK) does it.

Yeah, a complex infrastructure just to fix typos in commit messages
seems a bit over the top.

-Miles

-- 
Bore, n. A person who talks when you wish him to listen.

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Sat, Jan 2, 2010 at 06:24, Miles Bader <miles@gnu.org> wrote:

> Yeah, a complex infrastructure just to fix typos in commit messages
> seems a bit over the top.

Though I agree with you, let's not misrepresent the issue; changing
commit messages is not just about typos, but also wrong or misleading
information.

    Juanma

Re: Workflow to accumulate individual changes?

[Miles Bader]

Juanma Barranquero <lekktu@gmail.com> writes:
>> Yeah, a complex infrastructure just to fix typos in commit messages
>> seems a bit over the top.
>
> Though I agree with you, let's not misrepresent the issue; changing
> commit messages is not just about typos, but also wrong or misleading
> information.

Nonetheless, IME, it's _extremely_ rare for it to represent a serious
issue, and nowhere near enough of a problem to be worth the cost of such
a mechanism.

-Miles

-- 
Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans
in Scotland.

Re: Workflow to accumulate individual changes?

[Karl Fogel]

Miles Bader <miles@gnu.org> writes:
>Nonetheless, IME, it's _extremely_ rare for it to represent a serious
>issue, and nowhere near enough of a problem to be worth the cost of such
>a mechanism.

I don't know how rare it is, but I saw it be important once.  See

http://www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html#contribulyzer

Search for the phrase

  "after writing the Contribulyzer code to process log messages
  formatted according to the new standard, we could go back and fix up
  all of the project's existing logs to conform to that standard"

to jump straight to the paragraph about how editing log messages after
the fact made a big difference.

-Karl

Re: Workflow to accumulate individual changes?

[Stephen J. Turnbull]

Karl Fogel writes:

 > Search for the phrase
 > 
 >   "after writing the Contribulyzer code to process log messages
 >   formatted according to the new standard, we could go back and fix up
 >   all of the project's existing logs to conform to that standard"
 > 
 > to jump straight to the paragraph about how editing log messages after
 > the fact made a big difference.

For something like that you could use git-filter-branch and probably
the equivalent in bzr (there *is* an equivalent, but I think it
requires converting to fastimport format to use).  To avoid the rebase
issue, you'd maybe merge the resulting branch rather than rebase.

git-filter-branch is very fast, although bzr's equivalent would not be
if I'm correct about converting to fastimport format.  But it could
probably be made to be fast.

Re: Workflow to accumulate individual changes?

[Stephen J. Turnbull]

Karl Fogel writes:

 > There are other ways the system could work.  IIUC, in git the commit
 > message is *not* part of the change's identity,

No, in git the commit message is indeed part of the changes's
identity.  A commit is a strictly defined structure (that happens to
be UTF-8 text with a final, free-form "comment" field), and the whole
thing is hashed to get the SHA1 identifying the commit.

What git has (and Mercurial, though implemented very differently) is
tag *objects*.  The tag object can contain arbitrary content (eg, a
signature), but here it could be used in some conventional way (eg, by
naming it "<sha1>-log-<log-rev-no>" to record an edited message for
commit <sha1>.

 > But I don't know if git has a way of propagating those edits to
 > other clones;

git commit --amend creates a new commit, propagated in the usual way
for commits.  git tag -a creates an annotated tag, propagated in the
usual way for tags.

 > In any case, IMHO it is a minor feature regression that we can no longer
 > tweak log messages after the fact, but it's not a huge problem.

The problem is that in a DVCS there is no reasonable way to propagate
those changes, and it becomes an issue of what the "official" message
for that commit is.  Eg, suppose you tweak.  Now different "official"
messages are going to propagate -- some people already have that
commit, and will *not* refetch it because the identity (SHA1) hasn't
changed.  Others will update or clone, and get it.

In other words, in git the way to notify other clients that you've
changed the commit message is to change the commit ID.  This is true
of all of the DVCSes I've used.

Re: Workflow to accumulate individual changes?

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: Óscar_Fuentes <ofv@wanadoo.es>
 > > Date: Fri, 01 Jan 2010 05:03:57 +0100
 > > 
 > > Richard Stallman <rms@gnu.org> writes:
 > > 
 > > > Is there no way to fix an error in a commit message?
 > > 
 > > You can undo a commit with `bzr uncommit'.
 > 
 > But the issue is not to undo the commit, only fix the text of the
 > commit message.  Something similar to "cvs admin -mREV:MESSAGE".

There's no reason practical or otherwise not to do uncommit, then
commit again, as long as you're on a private branch.  git and darcs
provide "git commit --amend" and "darcs amend-commit" which do exactly
what you want, except that they change the identity of the commit (see
below).  Eg as a shell function

bzr-amend-last-commit () {
    COMMIT_LOG=$1
    bzr uncommit
    bzr commit -m "$COMMIT_LOG"
}

There are also filter-branch capabilities in both git and bzr (quite
expensive in bzr, though) that would allow you to amend an old commit
log on a private branch.

If I really needed to fix a message in a published git branch I would
use a heavyweight tag named "README-something".  I don't think there's
anything similar in bzr, though.

 > Typos in commit messages still can happen, even with bzr ;-)

This has been endlessly discussed on at least the Darcs and Bazaar
lists.

The gist is that the commit log is part of the historical record, and
is checksummed, along with the rest of the history data (eg date and
author information).  This checksum becomes part of the revision
identifier, and thus if you change any of the data, including the
commit log, you've changed the identity of the revision.  As described
elsewhere, that revision identifier is used in various places; it's
not an implemention-internal datum.

I don't think there's any theoretical problem with attaching the log
message externally (at least, external to the checksummed content) as
a comment, somehow.  However, from personal experience I can say that
while I still make the same number of typos in log messages as when I
was using CVS, I make far fewer errors of the form of omitting
important information because I commit much more frequently and my log
messages are both shorter (per message) and more detailed.  So I
suspect you'd get resistence to such a suggestion, both on principle
("The log message is part of history") and practically ("there's no
real benefit, it would take work to do, and it slightly weakens our
internal consistency guarantee").

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>,
>     emacs-devel@gnu.org
> Date: Fri, 01 Jan 2010 23:59:20 +0900
> 
> So I suspect you'd get resistence to such a suggestion, both on
> principle ("The log message is part of history") and practically
> ("there's no real benefit, it would take work to do, and it slightly
> weakens our internal consistency guarantee").

Forget it.  It's easier to set up flyspell for the log buffers.

Re: Workflow to accumulate individual changes?

[Alfred M. Szmidt]

       A major problem with generating the ChangeLog from the commit messages
       is that you cannot fix a incorrect entry.

   Is there no way to fix an error in a commit message?

That is the case, once one publishes a revision there is no way of
amending the commit message.

Re: Workflow to accumulate individual changes?

[David Kastrup]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> I think it's very useful to see file changes in the ChangeLog.  It
> helps a lot when an Emacs user downloads a tarball of the sources from
> the FTP site, because file changes are visible without full access to
> the original branch itself or access to a bzr client.

_IF_ the file change history is important, we can generate it on the
source web page on the fly, from the VCS logs.  ChangeLog dates from a
time of VCS-less development.  If we really want to distribute this sort
of info, generating it from commits is quite more reliable.

One point of a distributed version control system is that non-privileged
users may clone their own repository and have all this historical data
in case they need to work with it.

My vote is for moving ChangeLog maintenance to proper commit message
maintenance: that is more important for a developer with version control
access, and again, DVCS use means that this info is available off-line
to the user/programmer.  With CVS, it wasn't.

> Maybe we can try to strike a balance between not keeping the ChangeLog
> up to date at all and making it difficult to commit *one* changeset
> that includes both ChangeLog updates _and_ file updates by committing
> the ChangeLog updates separately?

I don't consider it useful anymore to artificially split relevant change
info between ChangeLog and commit messages: all relevant version control
tools (graphical browsers etc) access the commit messages, and those are
there also offline.

There is no info we want in ChangeLog that should be missing from commit
messages.

The price Emacs developers pay for following the proposed hair-splitting
policies now is too high.  With CVS, off-line access to the ChangeLog
was a somewhat valid argument.  With DVCS, it isn't.

-- 
David Kastrup

Re: Workflow to accumulate individual changes?

[Karl Fogel]

David Kastrup <dak@gnu.org> writes:
>_IF_ the file change history is important, we can generate it on the
>source web page on the fly, from the VCS logs.  ChangeLog dates from a
>time of VCS-less development.  If we really want to distribute this sort
>of info, generating it from commits is quite more reliable.
>
>One point of a distributed version control system is that non-privileged
>users may clone their own repository and have all this historical data
>in case they need to work with it.
>
>My vote is for moving ChangeLog maintenance to proper commit message
>maintenance: that is more important for a developer with version control
>access, and again, DVCS use means that this info is available off-line
>to the user/programmer.  With CVS, it wasn't.
>
>> Maybe we can try to strike a balance between not keeping the ChangeLog
>> up to date at all and making it difficult to commit *one* changeset
>> that includes both ChangeLog updates _and_ file updates by committing
>> the ChangeLog updates separately?
>
>I don't consider it useful anymore to artificially split relevant change
>info between ChangeLog and commit messages: all relevant version control
>tools (graphical browsers etc) access the commit messages, and those are
>there also offline.
>
>There is no info we want in ChangeLog that should be missing from commit
>messages.
>
>The price Emacs developers pay for following the proposed hair-splitting
>policies now is too high.  With CVS, off-line access to the ChangeLog
>was a somewhat valid argument.  With DVCS, it isn't.

+1 all over this.

Our commit logs should follow the same structure ChangeLog entries
currently do, and we should not maintain separate ChangeLog files.
There would be zero information loss; also much less confusion, and much
less time wasted discussing how to maintain the same information in two
places.

Re: Workflow to accumulate individual changes?

[Chong Yidong]

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

> Our commit logs should follow the same structure ChangeLog entries
> currently do, and we should not maintain separate ChangeLog files.

It's already been decided that we'll continue to maintain ChangeLog
files.  This is an awfully marginal issue, so let's not waste any more
time arguing.  Just write the ChangeLog entries the way we've all been
doing, and pull them into the commit log (`C-c C-a' if you're using VC).

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Our commit logs should follow the same structure ChangeLog entries
>> currently do, and we should not maintain separate ChangeLog files.
>
> It's already been decided that we'll continue to maintain ChangeLog
> files.  This is an awfully marginal issue, so let's not waste any more
> time arguing.

It's far from being a marginal issue, it affects the convenience of
Bazaar for most of the work that does not consists on committing to
upstream immediately (i.e. the centralized on-line workflow, CVS-style.)

I agree that discussing it now is worthless, though. After some weeks of
using Bazaar, people will experience the issues by themselves and then
it would be much more easier to reach a consensus.

[snip]

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 21:14, Chong Yidong <cyd@stupidchicken.com> wrote:

> Just write the ChangeLog entries the way we've all been doing,

...(hopefully) remembering to put that one-line summary at the start...

    Juanma

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Giorgos Keramidas <keramida@ceid.upatras.gr>
> Cc: Andreas Schwab <schwab@linux-m68k.org>, lekktu@gmail.com,
>         emacs-devel@gnu.org
> Date: Thu, 31 Dec 2009 15:43:57 +0200
> 
> On Thu, 31 Dec 2009 07:23:28 -0500, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: lekktu@gmail.com,  keramida@ceid.upatras.gr,  emacs-devel@gnu.org
> >> Date: Thu, 31 Dec 2009 12:44:46 +0100
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> > Are you suggesting that the commit message should not mention the
> >> > changes in individual files at all, just the general idea?
> >>
> >> Yes, that's what they are for.
> >
> > But then the corresponding ChangeLog entries should have the text
> > identical or very similar to the commit message in front of them, or
> > else have some other means of locating the log entries easily.
> 
> I think it's very useful to see file changes in the ChangeLog.

The issue at hand is whether to have them in the commit messages, not
in ChangeLog.  ChangeLog entries always include file and function
information, it's been like that since day one.

Re: Workflow to accumulate individual changes?

[Stefan Monnier]

> Maybe we can try to strike a balance between not keeping the ChangeLog
> up to date at all and making it difficult to commit *one* changeset that
> includes both ChangeLog updates _and_ file updates by committing the
> ChangeLog updates separately?  This way, we can have a very short
> summary in the ChangeLog commit, e.g.:

No, don't.  It's very simple to do it in a single commit: use C-x 4 a as
usual to write the ChangeLog, then use C-c C-a in the *vc-commit* buffer
to pull the ChangeLog text and then C-c C-c to do the commit of all the
files (including the ChangeLog).
The text is duplicated but written only once and that's what counts.

We may reconsider this in the future by dropping the ChangeLog file
(aka auto-constructing it from the commit logs), but not now.


        Stefan

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Thu, Dec 31, 2009 at 10:21, Andreas Schwab <schwab@linux-m68k.org> wrote:

> ChangeLog entries and commit messages serve a different purpose.
> ChangeLog entries describe the "physical" changes, a commit message the
> "logical" change.  That is, the commit message describes the changeset
> on a higher level than the ChangeLog entries.  As such it does not make
> sense to repeat the ChangeLog entries in the commit message.

We have plenty of ChangeLog entries that describe both, because it is
(or it was, with CVS) much easier/faster to look at the ChangeLog than
the cvs log. And most projects do survive withouth ChangeLogs, by
using the commit logs, and having a good interface to the VCS to make
the diffs easy to access. I think your distinction is theoretically
sound, but as a policy difficult to implement.

    Juanma

Workflow to accumulate individual changes?

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > Let's suppose I want to create a local post-23.2 branch where I do
 > want to commit small changes to install on the trunk post-release. I
 > don't want to be forced to create a task branch for every one of them,
 > because they are small changes, and a new branch implies having to
 > bootstrap[1] anew. So I'd like to accumulate the changes into a single
 > branch.

I don't understand what you're concerned about (yes, I've seen the
followup which includes the footnote).  If you follow the procedure
for creating a shared repository (described in BzrForEmacsDevs, among
other places), then all branches under the shared repository directory
share storage, and creating a branch is very cheap (ie, the cost of
copying the tree, which is small since you can use hardlinks).[1]  I
would think this would be fine for anything requiring more than one
commit.  In any case, I think it would be worth trying, you might find
it's perfectly satisfactory.

You can make this slightly cheaper by using "checkout --lightweight"
(but the main cost is still creating the tree).

If you have a series of one-commit changes, the cheapest way to do it
would be with rebase.  (N.B. I can't help you with "bzr rebase"
itself, I've never used it.)  The idea would be to put each commit in
the same branch.  You will almost certainly have exactly one conflict
per ChangeLog you touch, but after that your commits will take place
on top of the previous one, and should be fine (at least, I think bzr
is smart enough not to conflict again).

 > Once the trunk is open again, what would be the procedure to install
 > the changes?

If you follow any of the above, you would just follow the usual
procedure for installing as described in BzrForEmacsDevs.

 > Obviously not "bzr merge ../post-23.2", because that would create a
 > single [merge] commit.

Yup, see attached script[2].  I don't have a plugin, but I have a
script that you can use to simulate the workflow you propose (if
you're on Windows you'll need to .BATify or use Cygwin).  Tested and
works on Gentoo GNU/Linux.  Two workflows I tried unsuccessfully are
also documented there for posterity.


Footnotes: 
[1]  You may need to tune the branch command to use hardlinks instead
of copies.

[2]
# set up a trunk mirror as usual
# test code: uncomment next statement to test
TESTP=t
if test -n "$TESTP"; then
 newfile () { echo $1 > $1; bzr add $1; }
 addlog () { echo $1 > .tmp0; cat .tmp0 ChangeLog > .tmp1; mv .tmp1 ChangeLog; }
 cd /tmp
 mkdir shared-repo
 cd shared-repo
 bzr init-repo
 mkdir remote-trunk
 cd remote-trunk
 bzr init
 newfile ChangeLog
 newfile foo
 bzr commit -m "add foo"
 cd ..
 bzr checkout remote-trunk trunk
fi

# set up your post 23.2 branch
bzr branch trunk post-23.2
cd post-23.2

# hack ... commit ... hack ... commit ... until trunk open
# more test code
if test -n "$TESTP"; then
 newfile bar
 addlog 'add bar'
 bzr commit -m 'add bar'
 newfile baz
 addlog 'add baz'
 bzr commit -m 'add baz'
 # simulate concurrent work
 cd ../remote-trunk
 newfile quux
 addlog 'add quux'
 bzr commit -m 'add quux'
fi

# here's the install procedure itself
cd ../trunk
bzr update
# trunk is now up-to-date
cd ../post-23.2
# durn, in testing the update fails, branches have diverged
# bzr update
# durn, in testing the merge --pull succeeds but leaves you with the
# remote changes at the top
bzr merge --pull

# what I hoped for but doesn't actually work (it creates a true merge
# rather than a fast forward)
# cd ../trunk
# bzr pull ../post-23.2

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Fri, Jan 1, 2010 at 13:33, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> I don't understand what you're concerned about (yes, I've seen the
> followup which includes the footnote).

Well, if you read the note, you know what am I concerned about: not
the time for checking out the files, but the time to get the branch in
a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s,
while "make bootstrap" is ~20min. The only fix for that is creating a
script to copy .o, .elc and other generated files from another branch.
Quite a fuss just to commit (and store for the future) a one-liner;
that's why I think of having a branch for these micro-issues. (Well,
colocated branches à la git would be wonderful for this case...)

> and creating a branch is very cheap (ie, the cost of
> copying the tree, which is small since you can use hardlinks).[1]

As I've said above, it's not the time to create the branch that
worries me; that said, Bazaar does not support hardlinks on Windows,
AFAIK.

> I would think this would be fine for anything requiring more than one
> commit.  In any case, I think it would be worth trying, you might find
> it's perfectly satisfactory.

For more serious changes yes, absolutely.

> If you have a series of one-commit changes, the cheapest way to do it
> would be with rebase.

That seems to be the consensus, yes.

    Juanma

Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Jan 1, 2010 at 13:33, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
>> I don't understand what you're concerned about (yes, I've seen the
>> followup which includes the footnote).
>
> Well, if you read the note, you know what am I concerned about: not
> the time for checking out the files, but the time to get the branch in
> a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s,
> while "make bootstrap" is ~20min. The only fix for that is creating a
> script to copy .o, .elc and other generated files from another branch.
> Quite a fuss just to commit (and store for the future) a one-liner;
> that's why I think of having a branch for these micro-issues. (Well,
> colocated branches à la git would be wonderful for this case...)

https://launchpad.net/bzr-loom

It is underdocumented, but it works AFAIK. You can search the internet
for experiences with it.

OTOH, some people emulate colocated branches with `bzr switch'. The idea
is that you have a checkout for hacking that you bind to wathever branch
you chose to work on. For example, lets suppose that you created your
working checkout with:

bzr co trunk my-playground   # you need to do this only once

from now on, when you need a small feature, you create a branch for it:

bzr branch --no-tree trunk fix-foo

this is a very fast and inexpensive operation on a shared repository, as
it doesn't even require to create the working tree.

Now, if you want to work on `fix-foo', from `my-playground' you do

bzr switch ../fix-foo

you do something and, eventually

bzr commit -m "done!"

this will update `fix-foo'. Later, you can proced to merge the changes
from `fix-foo' into `trunk' as usual (taking care of the ChangeLog
issue.)

If now you wish to work on a new micro-feature:

cd ..    # from `my-playground'
bzr branch --no-tree fix-bar
cd my-playground
bzr status  # Test that you don't have pending changes!
bzr switch ../fix-bar

Note that, within a shared repository, you can organize your branches as
you wish, so it is advisable to make a directory `delayed-changes' and
create your mini-feature branches there.

[snip]

-- 
Óscar

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Sat, Jan 2, 2010 at 03:28, Óscar Fuentes <ofv@wanadoo.es> wrote:

> https://launchpad.net/bzr-loom
>
> It is underdocumented, but it works AFAIK. You can search the internet
> for experiences with it.

Yes, I know about loom, though I've not used it. And YES, it is
underdocumented :-)

AFAICS, looms are similar to colocated branches, but threads are
sorted, i.e., they have an order dependency.

> OTOH, some people emulate colocated branches with `bzr switch'. The idea
> is that you have a checkout for hacking that you bind to wathever branch
> you chose to work on. For example, lets suppose that you created your
> working checkout with:

And, in this case, my-playground would be usually in a runnable state,
and "bzr switch ../fix-foo" would only touch the updated files,
minimizing recompilation. Right? Neat idea, I'm gonna give it a try.
Thanks!

    Juanma

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Sat, 02 Jan 2010 03:28:31 +0100
> 
> If now you wish to work on a new micro-feature:
> 
> cd ..    # from `my-playground'
> bzr branch --no-tree fix-bar
> cd my-playground
> bzr status  # Test that you don't have pending changes!
> bzr switch ../fix-bar

Why is "bzr status" above important? what happens if I do have pending
changes before switching?

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Sat, Jan 2, 2010 at 10:11, Eli Zaretskii <eliz@gnu.org> wrote:

> Why is "bzr status" above important?

It shouldn't be needed, though it seems sensible to do it before
switching your tree...

> what happens if I do have pending
> changes before switching?

They get merged:

  [...] the working tree is updated and uncommitted changes
  are merged. The user can commit or revert these as they desire.

  Pending merges need to be committed or reverted before using switch.

Conflicts are marked as expected.

    Juanma

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On  Sat, Jan 2, 2010 at 03:28, Óscar Fuentes <ofv@wanadoo.es> wrote:

> OTOH, some people emulate colocated branches with `bzr switch'.

It works like a charm.

> Note that, within a shared repository, you can organize your branches as
> you wish, so it is advisable to make a directory `delayed-changes' and
> create your mini-feature branches there.

The fact that the branch for "bzr switch BRANCH" can be relative to
the parent dir makes this even easier.

It'd be worth documenting this somewhere to give it this higher
visibility, IMO, than a single paragraph in bzr help checkouts:

    Another possible use for a checkout is to use it with a treeless repository
    containing your branches, where you maintain only one working tree by
    switching the master branch that the checkout points to when you want to
    work on a different branch.

BTW, what's the use of "branch --switch"? Something like this:

  # trunk/     (main mirror)
  # my-playground/     ("working" checkout)
  # delayed-changes/branch1, branch2, etc.     (treeless branches)

  # from my-playground
  bzr branch --no-tree --switch ../trunk ../delayed-changes/branchN

so you create a new branch and switch to it in a single op? Sweet,
worth of an alias.

    Juanma

Re: Workflow to accumulate individual changes?

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > Well, if you read the note, you know what am I concerned about: not
 > the time for checking out the files, but the time to get the branch in
 > a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s,
 > while "make bootstrap" is ~20min.

Ah, I skipped over that.

The way that is often recommended to handle that is to have a test
tree, which is setup as a checkout.  So

bzr branch trunk build-test
cd build-test
make bootstrap
make test                 # if you like, but should be OK :-)
for i = 1 2 3; do
  cd ..
  bzr branch trunk fix$i
  cd fix$i
  # hack
  bzr commit -m "fix$i"
  cd ../build-test
  bzr checkout ../fix$i
  make                    # Look Ma, no 'bootstrap'!
  make test
done

YMMV, and caveat hacer: I haven't used this workflow personally, nor
have I tested that my command syntax is correct.

 > (Well, colocated branches à la git would be wonderful for this
 > case...)

Maybe someday, but AFAICS the main candidates for developing such
(Aaron Bentley and Robert Collins) are putting their efforts into
quilt-cum-VCS efforts ("pipelines" and "looms", respectively).

Somebody like you who has a fair amount of DVCS knowledge already (I
don't know how much that is exactly but I'm pretty sure from your
comments that it is sufficient for this) should look at pipelines
(similar to Mercurial queues, and maybe Stacked Git) and looms.
Pipelines really do have a sequential nature to them, which might or
might not get in the way, and AFAIK they don't yet have an mq-like
guard mechanism.  Looms are an original idea of Robert's and some
folks I really respect love them until the fur rubs off.  In
particular, they can sort of be abused in a "guard"-like fashion, I
think.

But it will require experimentation; neither pipelines nor looms are
documented up to Bazaar's usual standards.  (I agree with Eli about
those standards, by the way; that's why I think experimenting with
these requires "sufficient DVCS background".)

 > > If you have a series of one-commit changes, the cheapest way to do it
 > > would be with rebase.
 > 
 > That seems to be the consensus, yes.

The methods suggested above might be useful too.  For one-off patches,
I use mq all the time because Mercurial's support for colocated
branches "should be indented 6 feet downward", at least from my
relatively git-centric viewpoint.  But I also use guards extensively
because I often submit even one-offs for review, so it's not always
the case that writing order is push order.  I don't know offhand how
to emulate guards in bzr.

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sat, 02 Jan 2010 12:46:30 +0900
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> bzr branch trunk build-test
> cd build-test
> make bootstrap
> make test                 # if you like, but should be OK :-)
> for i = 1 2 3; do
>   cd ..
>   bzr branch trunk fix$i
>   cd fix$i
>   # hack
>   bzr commit -m "fix$i"
>   cd ../build-test
>   bzr checkout ../fix$i
>   make                    # Look Ma, no 'bootstrap'!
>   make test
> done

What is the semantics of "bzr checkout ../fix$i" in this case?  What
does it do, exactly?

Bazaar docs are not very clear on that, to say the least:

    Purpose: Create a new checkout of an existing branch.

But fix$i is already an existing branch, and one with local changes,
so this ``create'' seems not quite the right word here.

    Usage: bzr checkout [BRANCH_LOCATION] [TO_LOCATION]

    Description: If BRANCH_LOCATION is omitted, checkout will reconstitute
		 a working tree for the branch found in ‘.’.
		 [...]
		 If the TO_LOCATION is omitted, the last component of the
		 BRANCH_LOCATION will be used. In other words, “checkout
		 ../foo/bar” will attempt to create ./bar. If the
		 BRANCH_LOCATION has no / or path separator embedded,
		 the TO_LOCATION is derived from the BRANCH_LOCATION
		 by stripping a leading scheme or drive identifier, if
		 any. For example, “checkout lp:foo-bar” will attempt
		 to create ./foo-bar.

Again, ``create ./bar'' sounds incorrect in the context of your
suggestion.  ``Reconstitute a working tree'', OTOH, sounds too obscure
to help.

So what does this "checkout" do in this case?

(Btw, note the tricky convention regarding slashes, not for the faint
of heart IMO.)

Re: Workflow to accumulate individual changes?

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Sat, 02 Jan 2010 12:46:30 +0900
 > > Cc: Emacs developers <emacs-devel@gnu.org>

Urk, I'd been working in Mercurial and mixed semantics.  (I really,
really hate the way all the DVCSes insist on using each others'
command names and features but with different semantics attached to
the same name.)  I think Óscar got it right, though.  After testing,
this should be revised as below

 > > bzr branch trunk build-test

A lightweight checkout is often recommended here instead of branch:

    bzr checkout --lightweight trunk build-test

It's more efficient.

 > > cd build-test
 > > make bootstrap
 > > make test                 # if you like, but should be OK :-)
 > > for i = 1 2 3; do
 > >   cd ..
 > >   bzr branch trunk fix$i
 > >   cd fix$i
 > >   # hack
 > >   bzr commit -m "fix$i"
 > >   cd ../build-test

Oops, this is where I went WRONG:

 > >   bzr checkout ../fix$i

RIGHT:

bzr switch ../fix$i

 > >   make                    # Look Ma, no 'bootstrap'!
 > >   make test
 > > done
 > 
 > What is the semantics of "bzr checkout ../fix$i" in this case?  What
 > does it do, exactly?

(Checkout in fact will error here, or perhaps produce a fix$i subtree.
Not what you want.)

"bzr switch fix$i" says

    Purpose: Set the branch of a checkout and update.
    Usage:   bzr switch TO_LOCATION

    Options:
      --force              Switch even if local commits will be lost.
      -v, --verbose        Display more information.
      -q, --quiet          Only display errors and warnings.
      --usage              Show usage message and options.
      -b, --create-branch  Create the target branch from this one
                           before switching to it.
      -h, --help           Show help message.

    Description:
      For lightweight checkouts, this changes the branch being
      referenced.  For heavyweight checkouts, this checks that there
      are no local commits versus the current bound branch, then it
      makes the local branch a mirror of the new location and binds to
      it.

# In informal terms, the above says "this workspace now refers to the
# new branch for VCS information."

      In both cases, the working tree is updated and uncommitted
      changes are merged. The user can commit or revert these as they
      desire.

# The update happens automatically and immediately upon "bzr switch".
# In the workflow described above, the "uncommitted changes" are the
# build products generated by "make bootstrap", "make", and "make
# test".  In this workflow, no commits should ever happen in this
# tree; it is purely for the convenience of testing since you will
# have a usable bootstrapped tree.  (Of course if the changes from
# branch "fix1" to branch "fix2" would have broken the build and need
# a new "make bootstrap" under CVS, you'll need that here, too.)
  
      Pending merges need to be committed or reverted before using
      switch.

# The workflow described above should have no pending merges in this
# tree.  The only VCS operation you do here after initialization is
# "bzr switch", which is sort of like "cvs update -r" for this workflow.

      The path to the branch to switch to can be specified relative to
      the parent directory of the current branch. For example, if you
      are currently in a checkout of /path/to/branch, specifying
      'newbranch' will find a branch at /path/to/newbranch.

# Don't you just love DWIM?

      Bound branches use the nickname of its master branch unless it
      is set locally, in which case switching will update the the
      local nickname to be that of the master.

# I don't know what the above means, exactly; I don't use nicknames.

 > Bazaar docs are not very clear on that, to say the least:
 > 
 >     Purpose: Create a new checkout of an existing branch.
 > 
 > But fix$i is already an existing branch, and one with local changes,
 > so this ``create'' seems not quite the right word here.

My bad, I did warn that my syntax might be wrong.

 > (Btw, note the tricky convention regarding slashes, not for the faint
 > of heart IMO.)

Heh.  Emacsen users should be used to such things, though.

Re: Workflow to accumulate individual changes?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: lekktu@gmail.com,
>     emacs-devel@gnu.org
> Date: Sun, 03 Jan 2010 00:30:44 +0900
> 
>  > > cd build-test
>  > > make bootstrap
>  > > make test                 # if you like, but should be OK :-)
>  > > for i = 1 2 3; do
>  > >   cd ..
>  > >   bzr branch trunk fix$i
>  > >   cd fix$i
>  > >   # hack
>  > >   bzr commit -m "fix$i"
>  > >   cd ../build-test
> 
> Oops, this is where I went WRONG:
> 
>  > >   bzr checkout ../fix$i
> 
> RIGHT:
> 
> bzr switch ../fix$i

[snip]

Thanks, I'm saving these recipes for when I will need them.

Re: Workflow to accumulate individual changes?

[Juanma Barranquero]

On Sat, Jan 2, 2010 at 04:46, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> Somebody like you who has a fair amount of DVCS knowledge already (I
> don't know how much that is exactly

Not much, though a lot more than a couple months ago :-)

> should look at pipelines
> (similar to Mercurial queues, and maybe Stacked Git) and looms.

Yes, I have both installed. But when you say

> neither pipelines nor looms are
> documented up to Bazaar's usual standards.

that's an understatement :-)  After reading "bzr help loom", the first
question is, well, what's exactly a loom and what it is good for?
There are too many assumptions and too few clear statements of purpose
and use cases. pipeline is slightly better documented.

    Juanma