emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Emacs is on Bazaar now.


From: Karl Fogel
Subject: Re: GNU Emacs is on Bazaar now.
Date: Tue, 29 Dec 2009 01:14:50 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux)

Óscar Fuentes <address@hidden> writes:
>Well, there is no reason to settle on one Golden Workflow. It is clear
>that we want to introduce new good practices on how the VC history is
>developed (one changeset per purpose, etc) but that practices are not
>incompatible with multiple workflows. The feature branches workflow is
>great for substantial changes, but a PITA for one-liners. The
>centralized workflow is perfectly okay (unless you abuse it, or course,
>but you can abuse the distributed one: what stops you from mixing
>unrelated changes on the same merge?)
>
>Since long time ago I think that the main problem most people here have
>with the transition to bazaar is that they lack an insight on what a
>DVCS is (and some even have no previous experience with changeset-based
>VCSs!) People can understand the centralized usage of bzr without too
>much effort, but pushing some hackers here to blindly use the
>distributed workflow is asking for problems. A gradual introduction with
>a simpler workflow helps in several ways. That's a personal decission,
>no other is affected by it.
>
>Please lets not forget that this is not about making Emacs a model of
>orthodoxy in DVCS usage. It's about giving hackers a tool that helps
>them to contribute to Emacs.

Sure, I think everyone agrees on that.

So if people made their one-line changes this way:

  $ cd ${EMACS_DEV_AREA}/trunk
  $ bzr pull
  $ <<< make one-line obvious typo fix, edit ChangeLog file too >>>
  $ bzr commit -m "* README: Fix silly typo."
  <<< change automatically sent from local bound trunk to upstream trunk >>>
  $ 

would there be any negative consequences?  It violates the "keep local
trunk as pristine as possible" rule, and people will run into
complexities if upstream diverges from local trunk before their commit
is ready (they'd have to revert, re-pull, and redo, or something like
that).  Those are the reasons we didn't recommend it in the doc.  But
aside from those problems, could there be any negative consequences to
the versioned history?  I think not, but would like more knowledgeable
people to comment.

-Karl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]