Gnus development mailing list
 help / color / mirror / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: tzz@lifelogs.com, ding@gnus.org, emacs-devel@gnu.org
Subject: Re: Gnus overrides.texi and WEBHACKDEVEL
Date: Sun, 06 Feb 2011 23:40:25 +0900	[thread overview]
Message-ID: <878vxt1b1i.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <E1Pm1nm-0006iP-Sf@fencepost.gnu.org>

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.



  reply	other threads:[~2011-02-06 14:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-05  9:35 Revision 103117 on the Emacs trunk Eli Zaretskii
2011-02-05  9:52 ` Katsumi Yamaoka
2011-02-05 11:47   ` Eli Zaretskii
2011-02-05 12:16     ` Katsumi Yamaoka
2011-02-07 18:29       ` Ted Zlatanov
2011-02-08  3:49         ` Eli Zaretskii
2011-02-08  8:00           ` Peter Münster
2011-02-08  8:28             ` Eli Zaretskii
2011-02-08  8:50               ` Andreas Schwab
2011-02-08  9:06               ` Peter Münster
2011-02-08  9:28                 ` Eli Zaretskii
2011-02-08 14:33           ` -DWEBHACKDEVEL for Gnus (was: Revision 103117 on the Emacs trunk.) Ted Zlatanov
2011-02-08 15:23             ` -DWEBHACKDEVEL for Gnus Peter Münster
2011-02-05 13:08     ` Revision 103117 on the Emacs trunk Andreas Schwab
2011-02-05 14:21       ` Gnus overrides.texi and WEBHACKDEVEL (was: Revision 103117 on the Emacs trunk.) Ted Zlatanov
2011-02-05 15:12         ` Gnus overrides.texi and WEBHACKDEVEL Eli Zaretskii
2011-02-05 15:18           ` Ted Zlatanov
2011-02-05 15:39             ` Eli Zaretskii
2011-02-05 16:01               ` Ted Zlatanov
2011-02-07 19:06                 ` Eli Zaretskii
2011-02-07 19:19                   ` Ted Zlatanov
2011-02-07 19:47                   ` Eli Zaretskii
2011-02-06  6:49               ` Stephen J. Turnbull
2011-02-06 10:25                 ` Eli Zaretskii
2011-02-06 14:40                   ` Stephen J. Turnbull [this message]
2011-02-06 17:22                     ` Eli Zaretskii
2011-02-06 17:52                       ` Stephen J. Turnbull
2011-02-06 18:50                         ` Eli Zaretskii
2011-02-06 19:20                           ` Stephen J. Turnbull
2011-02-06 21:21                             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878vxt1b1i.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=ding@gnus.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=tzz@lifelogs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).