Revision 103117 on the Emacs trunk.

Revision 103117 on the Emacs trunk.

[Eli Zaretskii]

The doc/misc/ChangeLog entry for this revision says:

	* Makefile.in (webhack, nowebhack): Hacks to produce for-the-web
	manuals.

but there are no such targets in doc/misc/Makefile.in, and in fact the
merge commit includes no changes to doc/misc/Makefile.in at all.

What happened?

Re: Revision 103117 on the Emacs trunk.

[Katsumi Yamaoka]

Eli Zaretskii <eliz@gnu.org> wrote:
> The doc/misc/ChangeLog entry for this revision says:

> 	* Makefile.in (webhack, nowebhack): Hacks to produce for-the-web
> 	manuals.

> but there are no such targets in doc/misc/Makefile.in, and in fact the
> merge commit includes no changes to doc/misc/Makefile.in at all.

> What happened?

Sorry, I forgot merging a change to it.  I'll try it...

Re: Revision 103117 on the Emacs trunk.

[Eli Zaretskii]

> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: Ted Zlatanov <tzz@lifelogs.com>,  emacs-devel@gnu.org,  ding@gnus.org
> Date: Sat, 05 Feb 2011 18:52:08 +0900
> 
> Eli Zaretskii <eliz@gnu.org> wrote:
> > The doc/misc/ChangeLog entry for this revision says:
> 
> > 	* Makefile.in (webhack, nowebhack): Hacks to produce for-the-web
> > 	manuals.
> 
> > but there are no such targets in doc/misc/Makefile.in, and in fact the
> > merge commit includes no changes to doc/misc/Makefile.in at all.
> 
> > What happened?
> 
> Sorry, I forgot merging a change to it.  I'll try it...

Thanks.  However, your change is just this:

  === modified file 'doc/misc/Makefile.in'
  --- doc/misc/Makefile.in        2011-01-26 08:36:39 +0000
  +++ doc/misc/Makefile.in        2011-02-05 11:23:52 +0000
  @@ -209,6 +209,12 @@ mkinfodir = @cd ${srcdir}; test -d ${inf

   info: $(INFO_TARGETS)

  +webhack: clean
  +       echo '@set WEBHACKDEVEL' > overrides.texi
  +
  +nowebhack: clean
  +       echo '@clear WEBHACKDEVEL' > overrides.texi
  +
   dvi: $(DVI_TARGETS)

I think at least the prerequisites should be fixed, for those several
manuals which now depend on overrides.texi to build (unless we go the
way I suggest below).

Also, overrides.texi is in the repository, but these two new rules
will overwrite it, and the modified overrides.texi could then easily
be committed by mistake as part of the next "bzr ci", thus propagating
a file with "@set WEBHACKDEVEL" to everyone else.  That's bad, I
think.

Finally, I believe there are shells out there which will not overwrite
an existing file with the ">" redirection; you need to remove the file
first.

Bottom line, I think it will be much better to remove overrides.texi
altogether, and then modify the `webhack' target as follows:

  webhack:
  	$(MAKE) all MAKEINFO_OPTS="-DWEBHACKDEVEL --force -I$(emacsdir)"

Could you see if this will do what you want?

Re: Revision 103117 on the Emacs trunk.

[Katsumi Yamaoka]

Eli Zaretskii <eliz@gnu.org> wrote:
[...]
> Thanks.  However, your change is just this:

>   === modified file 'doc/misc/Makefile.in'
>   --- doc/misc/Makefile.in        2011-01-26 08:36:39 +0000
>   +++ doc/misc/Makefile.in        2011-02-05 11:23:52 +0000
>   @@ -209,6 +209,12 @@ mkinfodir = @cd ${srcdir}; test -d ${inf

>    info: $(INFO_TARGETS)

>   +webhack: clean
>   +       echo '@set WEBHACKDEVEL' > overrides.texi
>   +
>   +nowebhack: clean
>   +       echo '@clear WEBHACKDEVEL' > overrides.texi
>   +
>    dvi: $(DVI_TARGETS)

> I think at least the prerequisites should be fixed, for those several
> manuals which now depend on overrides.texi to build (unless we go the
> way I suggest below).

> Also, overrides.texi is in the repository, but these two new rules
> will overwrite it, and the modified overrides.texi could then easily
> be committed by mistake as part of the next "bzr ci", thus propagating
> a file with "@set WEBHACKDEVEL" to everyone else.  That's bad, I
> think.

> Finally, I believe there are shells out there which will not overwrite
> an existing file with the ">" redirection; you need to remove the file
> first.

> Bottom line, I think it will be much better to remove overrides.texi
> altogether, and then modify the `webhack' target as follows:

>   webhack:
>   	$(MAKE) all MAKEINFO_OPTS="-DWEBHACKDEVEL --force -I$(emacsdir)"

> Could you see if this will do what you want?

Thanks.  That's smarter.  But I think the last merge from Gnus was
too early, so I'll revert them.

Re: Revision 103117 on the Emacs trunk.

[Ted Zlatanov]

On Sat, 05 Feb 2011 21:16:54 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

KY> Thanks.  That's smarter.  But I think the last merge from Gnus was
KY> too early, so I'll revert them.

Is it OK to bring the change back with gnus-overrides.texi and
-DWEBHACKDEVEL?  Or are there objections still?

Ted

Re: Revision 103117 on the Emacs trunk.

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Mon, 07 Feb 2011 12:29:34 -0600
> Cc: ding@gnus.org
> 
> Is it OK to bring the change back with gnus-overrides.texi and
> -DWEBHACKDEVEL?  Or are there objections still?

I still think it's wrong to have a versioned file that needs to be
modified for some optional build.  It would be better to have the
Makefile create that file (as empty) as part of the build, if it
doesn't already exist.  Then it doesn't need to e in the repository,
and developers who need to invoke WEBHACKDEVEL will simply create it
before running Make.

Re: Revision 103117 on the Emacs trunk.

[Peter Münster]

Eli Zaretskii <eliz@gnu.org> writes:

> I still think it's wrong to have a versioned file that needs to be
> modified for some optional build.  It would be better to have the
> Makefile create that file (as empty) as part of the build, if it
> doesn't already exist.  Then it doesn't need to e in the repository,
> and developers who need to invoke WEBHACKDEVEL will simply create it
> before running Make.

Why not just a new target in the Makefile?
"make devel-pdf" and "make devel-html" ?
-- 
           Peter

Re: Revision 103117 on the Emacs trunk.

[Eli Zaretskii]

> From: pmlists@free.fr (Peter Münster)
> Date: Tue, 08 Feb 2011 09:00:17 +0100
> Cc: ding@gnus.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I still think it's wrong to have a versioned file that needs to be
> > modified for some optional build.  It would be better to have the
> > Makefile create that file (as empty) as part of the build, if it
> > doesn't already exist.  Then it doesn't need to e in the repository,
> > and developers who need to invoke WEBHACKDEVEL will simply create it
> > before running Make.
> 
> Why not just a new target in the Makefile?
> "make devel-pdf" and "make devel-html" ?

You mean, without any files to @include in the manuals?  If so, that's
what I suggested way back in the thread, but was told (I think by Ted)
that the included file allowed for more than just @set directives, and
that this additional flexibility, which is impossible to replace with
the -DFOO options to makeinfo, is anticipated to be needed in the
future.

Re: Revision 103117 on the Emacs trunk.

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> You mean, without any files to @include in the manuals?  If so, that's
> what I suggested way back in the thread, but was told (I think by Ted)
> that the included file allowed for more than just @set directives, and
> that this additional flexibility, which is impossible to replace with
> the -DFOO options to makeinfo, is anticipated to be needed in the
> future.

Which is of course a bogus argument, since you can always add more
@ifset controls to the texi file.

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: Revision 103117 on the Emacs trunk.

[Peter Münster]

Eli Zaretskii <eliz@gnu.org> writes:

>> Why not just a new target in the Makefile?
>> "make devel-pdf" and "make devel-html" ?
>
> You mean, without any files to @include in the manuals?  If so, that's
> what I suggested way back in the thread, but was told (I think by Ted)
> that the included file allowed for more than just @set directives, and
> that this additional flexibility, which is impossible to replace with
> the -DFOO options to makeinfo, is anticipated to be needed in the
> future.

I don't know makeinfo, but I know that make can do whatever you want,
for example:
- create temporary file with arbitrary content (echo ... >file)
- call makeinfo
- remove the temporary file (or not, whatever)

-- 
           Peter

Re: Revision 103117 on the Emacs trunk.

[Eli Zaretskii]

> From: pmlists@free.fr (Peter Münster)
> Date: Tue, 08 Feb 2011 10:06:23 +0100
> Cc: ding@gnus.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Why not just a new target in the Makefile?
> >> "make devel-pdf" and "make devel-html" ?
> >
> > You mean, without any files to @include in the manuals?  If so, that's
> > what I suggested way back in the thread, but was told (I think by Ted)
> > that the included file allowed for more than just @set directives, and
> > that this additional flexibility, which is impossible to replace with
> > the -DFOO options to makeinfo, is anticipated to be needed in the
> > future.
> 
> I don't know makeinfo, but I know that make can do whatever you want,
> for example:
> - create temporary file with arbitrary content (echo ... >file)
> - call makeinfo
> - remove the temporary file (or not, whatever)

You are repeating my suggestion, just in different words.  It was
rejected, so your argument is not with me.

-DWEBHACKDEVEL for Gnus (was: Revision 103117 on the Emacs trunk.)

[Ted Zlatanov]

On Tue, 08 Feb 2011 05:49:15 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Is it OK to bring the change back with gnus-overrides.texi and
>> -DWEBHACKDEVEL?  Or are there objections still?

EZ> I still think it's wrong to have a versioned file that needs to be
EZ> modified for some optional build.  

I absolutely agree.  But that is no longer the case.
gnus-overrides.texi is a static file now, intended for generic
Gnus-related @set commands and currently empty.

On Tue, 08 Feb 2011 10:06:23 +0100 pmlists@free.fr (Peter Münster) wrote: 

PM> I know that make can do whatever you want,

Oh, I wish that was true, but `make' is horribly limited.  Unfortunately
it's just good enough to make hacks on top of it popular.

On Tue, 08 Feb 2011 09:50:28 +0100 Andreas Schwab <schwab@linux-m68k.org> wrote: 

AS> Eli Zaretskii <eliz@gnu.org> writes:

>> You mean, without any files to @include in the manuals?  If so, that's
>> what I suggested way back in the thread, but was told (I think by Ted)
>> that the included file allowed for more than just @set directives, and
>> that this additional flexibility, which is impossible to replace with
>> the -DFOO options to makeinfo, is anticipated to be needed in the
>> future.

AS> Which is of course a bogus argument, since you can always add more
AS> @ifset controls to the texi file.

Andreas, can you explain which argument is bogus?  There are three in
the cited paragraph.  If you're referring to my justification for
gnus-overrides.texi that Eli explained, can you explain how you'd rather
do it?  For example, how would you set 20 GNUS_x variables efficiently
for all the Gnus manuals (keeping in mind the same process has to work
for Gnus and Emacs both)?

Thanks
Ted

Re: -DWEBHACKDEVEL for Gnus

[Peter Münster]

Ted Zlatanov <tzz@lifelogs.com> writes:

> PM> I know that make can do whatever you want,
>
> Oh, I wish that was true, but `make' is horribly limited.  Unfortunately
> it's just good enough to make hacks on top of it popular.

Better: make can call any external program, and the external program can
do whatever you want... ;-)

-- 
           Peter

Re: Revision 103117 on the Emacs trunk.

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Also, overrides.texi is in the repository, but these two new rules
> will overwrite it, and the modified overrides.texi could then easily
> be committed by mistake as part of the next "bzr ci", thus propagating
> a file with "@set WEBHACKDEVEL" to everyone else.  That's bad, I
> think.

It won't work when building outside srcdir anyway.

>   webhack:
>   	$(MAKE) all MAKEINFO_OPTS="-DWEBHACKDEVEL --force -I$(emacsdir)"

That should be

	$(MAKE) all MAKEINFO_OPTS="-DWEBHACKDEVEL $(MAKEINFO_OPTS)"

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

Gnus overrides.texi and WEBHACKDEVEL (was: Revision 103117 on the Emacs trunk.)

[Ted Zlatanov]

On Sat, 05 Feb 2011 14:08:55 +0100 Andreas Schwab <schwab@linux-m68k.org> wrote: 

AS> Eli Zaretskii <eliz@gnu.org> writes:
>> Also, overrides.texi is in the repository, but these two new rules
>> will overwrite it, and the modified overrides.texi could then easily
>> be committed by mistake as part of the next "bzr ci", thus propagating
>> a file with "@set WEBHACKDEVEL" to everyone else.  That's bad, I
>> think.

AS> It won't work when building outside srcdir anyway.

>> webhack:
>> $(MAKE) all MAKEINFO_OPTS="-DWEBHACKDEVEL --force -I$(emacsdir)"

AS> That should be

AS> 	$(MAKE) all MAKEINFO_OPTS="-DWEBHACKDEVEL $(MAKEINFO_OPTS)"

(I adjusted the Subject line so it's useful to Gnus developers and users
too)

That's what I wanted (and why I said overrides.texi was a hack :) except
the PDF and HTML targets are desired; I comitted a change to Gnus
accordingly to just do PDF for now.  Let me know what you think.

Now, overrides.texi is for Gnus manuals overrides: settings we may want
to propagate to all our manuals.  So I think it makes sense to have it,
just not the way I did it with shell redirection.  I renamed it to
gnus-overrides.texi and it can be used for things we want to use in all
the Gnus manuals in the future.  I hope that's OK with everyone; if not
it's easy enough to pull that include out.

Ted

Re: Gnus overrides.texi and WEBHACKDEVEL

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sat, 05 Feb 2011 08:21:18 -0600
> Cc: ding@gnus.org
> 
> Now, overrides.texi is for Gnus manuals overrides: settings we may want
> to propagate to all our manuals.  So I think it makes sense to have it,
> just not the way I did it with shell redirection.  I renamed it to
> gnus-overrides.texi and it can be used for things we want to use in all
> the Gnus manuals in the future.  I hope that's OK with everyone; if not
> it's easy enough to pull that include out.

I don't necessarily see a problem, but I don't understand why you need
a .texi file for these overrides.  At least the "@set FOO" part of
those overrides can be easily handled by add -DFOO switch to
MAKEINFO_OPTS.

More generally, what is a user supposed to do if she does want to put
something on gnus-overrides.texi?  That's a versioned file, so "bzr
status" will show it as modified, and there's still a danger of having
it committed inadvertently.  How is this better than just modifying
gnu.texi or any other file directly?

Re: Gnus overrides.texi and WEBHACKDEVEL

[Ted Zlatanov]

On Sat, 05 Feb 2011 17:12:01 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Sat, 05 Feb 2011 08:21:18 -0600
>> Cc: ding@gnus.org
>> 
>> Now, overrides.texi is for Gnus manuals overrides: settings we may want
>> to propagate to all our manuals.  So I think it makes sense to have it,
>> just not the way I did it with shell redirection.  I renamed it to
>> gnus-overrides.texi and it can be used for things we want to use in all
>> the Gnus manuals in the future.  I hope that's OK with everyone; if not
>> it's easy enough to pull that include out.

EZ> I don't necessarily see a problem, but I don't understand why you need
EZ> a .texi file for these overrides.  At least the "@set FOO" part of
EZ> those overrides can be easily handled by add -DFOO switch to
EZ> MAKEINFO_OPTS.

It's for general text variables which are awkward in Makefiles,
especially if we need many.  I can see many uses in the Gnus manuals.

EZ> More generally, what is a user supposed to do if she does want to put
EZ> something on gnus-overrides.texi?  That's a versioned file, so "bzr
EZ> status" will show it as modified, and there's still a danger of having
EZ> it committed inadvertently.  How is this better than just modifying
EZ> gnu.texi or any other file directly?

The user wouldn't touch them, they are for the developers.  I guess
"gnus-includes.texi" would be a less confusing name?

Ted

Re: Gnus overrides.texi and WEBHACKDEVEL

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sat, 05 Feb 2011 09:18:37 -0600
> Cc: ding@gnus.org
> 
> EZ> More generally, what is a user supposed to do if she does want to put
> EZ> something on gnus-overrides.texi?  That's a versioned file, so "bzr
> EZ> status" will show it as modified, and there's still a danger of having
> EZ> it committed inadvertently.  How is this better than just modifying
> EZ> gnu.texi or any other file directly?
> 
> The user wouldn't touch them, they are for the developers.

By "user" I _did_ mean developers in this case.  How do we prevent the
danger of committing a modified file?  Versioned files that are
modified are generally meant to be committed at some point.

If you want to have a file that Gnus manuals will include, how about
modifying Makefile.in to create an empty file during the build
procedure, if such a file does not already exist?  Then this file will
not have to be part of the repository, and developers who want to
build modified manuals will create a non-empty file before building
the manual.

> I guess "gnus-includes.texi" would be a less confusing name?

"gnu-manual-options.texi" sounds better.  But its name is not a
terribly important issue.

Re: Gnus overrides.texi and WEBHACKDEVEL

[Ted Zlatanov]

On Sat, 05 Feb 2011 17:39:33 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Sat, 05 Feb 2011 09:18:37 -0600
>> Cc: ding@gnus.org
>> 
EZ> More generally, what is a user supposed to do if she does want to put
EZ> something on gnus-overrides.texi?  That's a versioned file, so "bzr
EZ> status" will show it as modified, and there's still a danger of having
EZ> it committed inadvertently.  How is this better than just modifying
EZ> gnu.texi or any other file directly?
>> 
>> The user wouldn't touch them, they are for the developers.

EZ> By "user" I _did_ mean developers in this case.  How do we prevent the
EZ> danger of committing a modified file?  Versioned files that are
EZ> modified are generally meant to be committed at some point.

I see what you mean.  I want to use it differently, not for temporary
modifications but for regular use.  If it's modified, it should be
committed by the developer.  It's supposed to be in the VCS and
unchanging regardless of the make actions taken by the user.

Ted

Re: Gnus overrides.texi and WEBHACKDEVEL

[Eli Zaretskii]

The log for revision 103136 says:

  gnus-overrides.texi: Renamed from overrides.texi and all the relevant manuals use it now.

But there's no gnus-overrides.texi in the repository.  So the relevant
manuals cannot be built.

Re: Gnus overrides.texi and WEBHACKDEVEL

[Ted Zlatanov]

On Mon, 07 Feb 2011 21:06:23 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> The log for revision 103136 says:

EZ>   gnus-overrides.texi: Renamed from overrides.texi and all the relevant manuals use it now.

EZ> But there's no gnus-overrides.texi in the repository.  So the relevant
EZ> manuals cannot be built.

It looks present (empty, as it's supposed to be) for me, I just checked.  Am I missing something?

Ted

Re: Gnus overrides.texi and WEBHACKDEVEL

[Eli Zaretskii]

> Date: Mon, 07 Feb 2011 21:06:23 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> CC: emacs-devel@gnu.org, ding@gnus.org
> 
> 
> But there's no gnus-overrides.texi in the repository.  So the relevant
> manuals cannot be built.

Sorry, it was my stupid mistake (exacerbated by the fact that
overrides.texi was "bzr remove"d instead of "bzr rename"d into
gnus-overrides.texi).

Re: Gnus overrides.texi and WEBHACKDEVEL

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > By "user" I _did_ mean developers in this case.  How do we prevent the
 > danger of committing a modified file?

By using a real branch instead of a checkout.

Re: Gnus overrides.texi and WEBHACKDEVEL

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Ted Zlatanov <tzz@lifelogs.com>,
>     ding@gnus.org,
>     emacs-devel@gnu.org
> Date: Sun, 06 Feb 2011 15:49:08 +0900
> 
> Eli Zaretskii writes:
> 
>  > By "user" I _did_ mean developers in this case.  How do we prevent the
>  > danger of committing a modified file?
> 
> By using a real branch instead of a checkout.

Are you saying that "bzr push" will somehow catch these problems where
"bzr commit" in a bound branch doesn't?

Even if so, the wiki recommends to use a bound branch, and I assume
most (if not all) committers indeed use that.

Re: Gnus overrides.texi and WEBHACKDEVEL

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Cc: Ted Zlatanov <tzz@lifelogs.com>,
 > >     ding@gnus.org,
 > >     emacs-devel@gnu.org
 > > Date: Sun, 06 Feb 2011 15:49:08 +0900
 > > 
 > > Eli Zaretskii writes:
 > > 
 > >  > By "user" I _did_ mean developers in this case.  How do we prevent the
 > >  > danger of committing a modified file?
 > > 
 > > By using a real branch instead of a checkout.
 > 
 > Are you saying that "bzr push" will somehow catch these problems where
 > "bzr commit" in a bound branch doesn't?

Of course not.  I'm saying that one needs to use an appropriate
workflow to get the desired behavior.  Bazaar is *designed* to make it
easy to screw up this way because it is a *feature* for most people.
Your mileage apparently varies here.  Of course, Bazaar *also* makes
it easy to adapt workflows so that one must try to screw up this way.
The choice is yours.

Note that it *must* be yours.  The tool has to trust the user to know
what she's doing; if she says "commit", it commits; if she has things
so that "commit" to mean "commit and push if possible", it should do
that.  At least Bazaar gives you that choice.  The behavior you
dislike here is exactly the behavior you would get from CVS or
Subversion in a similar workflow, with no choice.

 > Even if so, the wiki recommends to use a bound branch, and I assume
 > most (if not all) committers indeed use that.

The wiki does *not* recommend *committing new content* in the bound
branch.  It recommends *pushing* "through" it to the public
repository.  (At least it did when I last touched it; wikis being what
they are, I don't know if it still recommends that.)

There are reasons why I was at such pains to discourage use of
checkouts.  This is one: you are simply running into the limitations
of simplistic workflows.

It seems to me that Emacs has arrived at the point where some of the
folks (but by far not all) who resisted sophisticated workflows are
going to have to bite the bullet and learn them, and specifically
learn some of the details of how Bazaar implements them.

Re: Gnus overrides.texi and WEBHACKDEVEL

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: tzz@lifelogs.com,
>     ding@gnus.org,
>     emacs-devel@gnu.org
> Date: Sun, 06 Feb 2011 23:40:25 +0900
> 
> Eli Zaretskii writes:
>  > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
>  > > Cc: Ted Zlatanov <tzz@lifelogs.com>,
>  > >     ding@gnus.org,
>  > >     emacs-devel@gnu.org
>  > > Date: Sun, 06 Feb 2011 15:49:08 +0900
>  > > 
>  > > Eli Zaretskii writes:
>  > > 
>  > >  > By "user" I _did_ mean developers in this case.  How do we prevent the
>  > >  > danger of committing a modified file?
>  > > 
>  > > By using a real branch instead of a checkout.
>  > 
>  > Are you saying that "bzr push" will somehow catch these problems where
>  > "bzr commit" in a bound branch doesn't?
> 
> Of course not.  I'm saying that one needs to use an appropriate
> workflow to get the desired behavior.

So what workflow will avoid this danger?  Can you show the commands in
that workflow for when a changeset is ready to be committed to the
master repo?

Re: Gnus overrides.texi and WEBHACKDEVEL

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > So what workflow will avoid this danger?  Can you show the commands in
 > that workflow for when a changeset is ready to be committed to the
 > master repo?

I don't have the time to figure that out (I don't use Bazaar heavily
enough to remember the details of the commands, nor do I remember the
details of the workflow in question).

But it's a simple, generic observation: if you have some changes that
should be pushed, and others (that may be worth preserving) that
should not be pushed, use a branch to work in.  Then cherrypick the
changes to your integration workspace (which can be a branch or a
checkout).  Finally push the commits from the integration workspace.

Another possibility would be use of pipelines or looms (but I can't
help you there at all, I've never used either).  I presume both of
those depend on having a true branch, as well, but they are designed
for "work in the integration branch".

Re: Gnus overrides.texi and WEBHACKDEVEL

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: tzz@lifelogs.com,
>     ding@gnus.org,
>     emacs-devel@gnu.org
> Date: Mon, 07 Feb 2011 02:52:45 +0900
> 
> But it's a simple, generic observation: if you have some changes that
> should be pushed, and others (that may be worth preserving) that
> should not be pushed, use a branch to work in.  Then cherrypick the
> changes to your integration workspace (which can be a branch or a
> checkout).  Finally push the commits from the integration workspace.

If this is what you had in mind, then it's still manual work, and
thus prone to errors.  I can do the same in a bound branch with
"bzr ci FILE1 FILE2 ...", thus "cherrypicking" only what should be
pushed.

The original problem was that some people do not pay attention to what
"bzr status" says, and just do a "bzr ci", which pushes all the
modified files.  I guess there's no way around vigilance.  Which is
fine with me.

Thanks.

Re: Gnus overrides.texi and WEBHACKDEVEL

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > If this is what you had in mind, then it's still manual work, and
 > thus prone to errors.  I can do the same in a bound branch with
 > "bzr ci FILE1 FILE2 ...", thus "cherrypicking" only what should be
 > pushed.

Not necessarily.  For example, you may have pushable and non-pushable
changes in the same file, in which case that doesn't allow you to
select what to commit.  Also, if the local changes would benefit from
being preserved, you can commit them *immediately*, so the problem
becomes more granular (and you can add hints to the commit message to
indicate that some commits should not be cherry-picked).  In some
VCSes, there are tools that allow you to prohibit pulling certain
revisions (eg, svnmerge.py), but I don't think bzr has such yet.

 > The original problem was that some people do not pay attention to what
 > "bzr status" says, and just do a "bzr ci", which pushes all the
 > modified files.  I guess there's no way around vigilance.

No, there isn't.  However, committing all changes, using
branch-per-feature in your workflow, and using appropriate commit
messages for coherent changesets can reduce the amount of effort
needed to implement vigilance.  All of which are best practices, and
don't involve that much extra effort once you're disciplined to them.

Re: Gnus overrides.texi and WEBHACKDEVEL

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: tzz@lifelogs.com,
>     ding@gnus.org,
>     emacs-devel@gnu.org
> Date: Mon, 07 Feb 2011 04:20:39 +0900
> 
>  > The original problem was that some people do not pay attention to what
>  > "bzr status" says, and just do a "bzr ci", which pushes all the
>  > modified files.  I guess there's no way around vigilance.
> 
> No, there isn't.  However, committing all changes, using
> branch-per-feature in your workflow, and using appropriate commit
> messages for coherent changesets can reduce the amount of effort
> needed to implement vigilance.

True.