* bzr workflow
@ 2010-01-11 21:10 Sam Steingold
2010-01-11 21:35 ` Andreas Schwab
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Sam Steingold @ 2010-01-11 21:10 UTC (permalink / raw
To: emacs-devel
http://www.emacswiki.org/emacs/BzrForEmacsDevs
appears to indicate that I need to commit _twice_ for each change (with the
same log message?):
Workflow for a Quick Change
...
bzr commit -m "Fix bla bla bla (closes Bug #1)."
Merging Into the Upstream Master
...
bzr merge
bzr commit -m "Merge: fix bla bla bla (closes Bug #1)."
1. Am I the only one who thinks this is a little too convoluted? (the only
other DVC I regularly use is hg, and there the workflow is "commit+push"
instead of the recommended emacs workflow "commit+merge+commit").
2. Is there a way to emacs-automate this? I.e., the first commit is easily done
from under emacs using the vc-dir buffer: mark the files, hit C-x v v to the to
the commit message buffer, then C-c C-a will insert the ChangeLog text and C-c
C-c will commit. Then I have to switch to a bash window, go to trunk, then
merge, and the then commit - but then I need either a second vc-dir buffer in
emacs, or I need to do that (a multi-line commit message!) from the shell.
There must be a better way to do that!
thanks.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-11 21:10 bzr workflow Sam Steingold
@ 2010-01-11 21:35 ` Andreas Schwab
2010-01-11 21:57 ` Sam Steingold
2010-01-11 21:37 ` Óscar Fuentes
2010-01-11 22:08 ` Eli Zaretskii
2 siblings, 1 reply; 29+ messages in thread
From: Andreas Schwab @ 2010-01-11 21:35 UTC (permalink / raw
To: Sam Steingold; +Cc: emacs-devel
Sam Steingold <sds@gnu.org> writes:
> 1. Am I the only one who thinks this is a little too convoluted? (the only
> other DVC I regularly use is hg, and there the workflow is "commit+push"
> instead of the recommended emacs workflow "commit+merge+commit").
Nothing stops you from using the more advanced workflow.
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."
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-11 21:10 bzr workflow Sam Steingold
2010-01-11 21:35 ` Andreas Schwab
@ 2010-01-11 21:37 ` Óscar Fuentes
2010-01-11 22:13 ` Chong Yidong
2010-01-12 7:47 ` Jan Djärv
2010-01-11 22:08 ` Eli Zaretskii
2 siblings, 2 replies; 29+ messages in thread
From: Óscar Fuentes @ 2010-01-11 21:37 UTC (permalink / raw
To: emacs-devel
Sam Steingold <sds@gnu.org> writes:
> http://www.emacswiki.org/emacs/BzrForEmacsDevs
> appears to indicate that I need to commit _twice_ for each change (with the
> same log message?):
This was extensively discussed here a few days ago.
> Workflow for a Quick Change
> ...
> bzr commit -m "Fix bla bla bla (closes Bug #1)."
>
> Merging Into the Upstream Master
> ...
> bzr merge
> bzr commit -m "Merge: fix bla bla bla (closes Bug #1)."
>
>
> 1. Am I the only one who thinks this is a little too convoluted?
No, you are not alone.
You can use
http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs
or a variation of it as described below.
There is something that I disagree with BzrForEmacsDevs: a quickfix that
requires more than one commit or that spans so long in time to warrant a
merge from upstream does not qualify as a quickfix for me.
For the people that works with the distributed workflow and thinks that
a quickfix should map to one and only one commit, there is an easy
solution: bind your quickfixes/ branch to upstream:
cd quickfixes/
bzr bind URL_TO_UPSTREAM/trunk
after this, your workflow for quick fixes becomes:
bzr up
bzr commit -m "Fix bla bla bla (closes Bug #1)."
and you can use VC-dir all along.
[snip]
--
Óscar
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-11 21:35 ` Andreas Schwab
@ 2010-01-11 21:57 ` Sam Steingold
2010-01-11 23:05 ` Andreas Schwab
0 siblings, 1 reply; 29+ messages in thread
From: Sam Steingold @ 2010-01-11 21:57 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
On 1/11/10, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Sam Steingold <sds@gnu.org> writes:
>
> > 1. Am I the only one who thinks this is a little too convoluted? (the only
> > other DVC I regularly use is hg, and there the workflow is "commit+push"
> > instead of the recommended emacs workflow "commit+merge+commit").
>
>
> Nothing stops you from using the more advanced workflow.
what "more advanced workflow"?
http://www.emacswiki.org/emacs/BzrForEmacsDevs
It might occur to you to save some effort by just doing bzr push
directly to the upstream master from inside the quickfixes branch:
cd $DEVHOME/emacs/quickfixes
bzr push sftp://USERNAME@bzr.savannah.gnu.org/srv/bzr/emacs/trunk/
Do not do this — it can cause history to be displayed in a strange way
in the upstream master, any mirrors or branches of it, and your own
branch later. Search for the word “hidden” in this mail for more
details.
--
Sam Steingold <http://sds.podval.org>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-11 21:10 bzr workflow Sam Steingold
2010-01-11 21:35 ` Andreas Schwab
2010-01-11 21:37 ` Óscar Fuentes
@ 2010-01-11 22:08 ` Eli Zaretskii
2 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2010-01-11 22:08 UTC (permalink / raw
To: Sam Steingold; +Cc: emacs-devel
> From: Sam Steingold <sds@gnu.org>
> Date: Mon, 11 Jan 2010 16:10:03 -0500
>
> http://www.emacswiki.org/emacs/BzrForEmacsDevs
> appears to indicate that I need to commit _twice_ for each change (with the
> same log message?):
>
> Workflow for a Quick Change
> ...
> bzr commit -m "Fix bla bla bla (closes Bug #1)."
>
> Merging Into the Upstream Master
> ...
> bzr merge
> bzr commit -m "Merge: fix bla bla bla (closes Bug #1)."
It's not twice, it's n+1, where n is the number of commits you do on
the quickfixes branch while you work on the change, and the +1 is to
merge with upstream before you send the changes to the remote
repository on Savannah. For serious development, you will want that,
and you cannot avoid the last merge with upstream, of course, for
obvious reasons.
As others told you, if your "quick fix" is just a simple change, it
doesn't need a separate branch. FWIW, I make such changes directly in
the trunk tree, and then the workflow looks very similar to CVS: just
hack, test, and commit once, which commits to the remote repository as
well as the local one.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-11 21:37 ` Óscar Fuentes
@ 2010-01-11 22:13 ` Chong Yidong
2010-01-12 7:47 ` Jan Djärv
1 sibling, 0 replies; 29+ messages in thread
From: Chong Yidong @ 2010-01-11 22:13 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
Óscar Fuentes <ofv@wanadoo.es> writes:
> No, you are not alone.
>
> You can use
>
> http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs
>
> or a variation of it as described below.
>
> There is something that I disagree with BzrForEmacsDevs: a quickfix that
> requires more than one commit or that spans so long in time to warrant a
> merge from upstream does not qualify as a quickfix for me.
Agree. I've edited the language in the two documents so that they do
not recommend one workflow over another. The ability to use VC-dir is
important.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-11 21:57 ` Sam Steingold
@ 2010-01-11 23:05 ` Andreas Schwab
0 siblings, 0 replies; 29+ messages in thread
From: Andreas Schwab @ 2010-01-11 23:05 UTC (permalink / raw
To: Sam Steingold; +Cc: emacs-devel
Sam Steingold <sds@gnu.org> writes:
> On 1/11/10, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Sam Steingold <sds@gnu.org> writes:
>>
>> > 1. Am I the only one who thinks this is a little too convoluted? (the only
>> > other DVC I regularly use is hg, and there the workflow is "commit+push"
>> > instead of the recommended emacs workflow "commit+merge+commit").
>>
>>
>> Nothing stops you from using the more advanced workflow.
>
> what "more advanced workflow"?
The one you are used to.
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."
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-11 21:37 ` Óscar Fuentes
2010-01-11 22:13 ` Chong Yidong
@ 2010-01-12 7:47 ` Jan Djärv
2010-01-12 8:40 ` Óscar Fuentes
2010-01-12 19:35 ` Eli Zaretskii
1 sibling, 2 replies; 29+ messages in thread
From: Jan Djärv @ 2010-01-12 7:47 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
Óscar Fuentes skrev:
>
> There is something that I disagree with BzrForEmacsDevs: a quickfix that
> requires more than one commit or that spans so long in time to warrant a
> merge from upstream does not qualify as a quickfix for me.
>
This is too simple. There have been many times in the CVS days when I tried
to commit a change only to find out there was a conflict (usually ChangeLog).
So I always merge from upstream before committing to upstream. So what you
are saying is in fact, there are no quick fixes.
What starts out as a (presumed) quickfix often turns in to a week/month long
fix. To assume that one can always beforehand descide if one is about to do a
quickfix or not is also too simple minded.
Bzr feels very strange and uncomfortable. It is workable, but not smooth or
elegant, just kind of icky.
Jan D.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-12 7:47 ` Jan Djärv
@ 2010-01-12 8:40 ` Óscar Fuentes
2010-01-12 9:39 ` Jan Djärv
2010-01-12 19:35 ` Eli Zaretskii
1 sibling, 1 reply; 29+ messages in thread
From: Óscar Fuentes @ 2010-01-12 8:40 UTC (permalink / raw
To: emacs-devel
Jan Djärv <jan.h.d@swipnet.se> writes:
> Óscar Fuentes skrev:
>
>>
>> There is something that I disagree with BzrForEmacsDevs: a quickfix that
>> requires more than one commit or that spans so long in time to warrant a
>> merge from upstream does not qualify as a quickfix for me.
>>
>
> This is too simple. There have been many times in the CVS days when I
> tried to commit a change only to find out there was a conflict
> (usually ChangeLog). So I always merge from upstream before committing
> to upstream.
That's what `bzr up' does on a bound branch or checkout.
> So what you are saying is in fact, there are no quick fixes.
>
> What starts out as a (presumed) quickfix often turns in to a
> week/month long fix. To assume that one can always beforehand descide
> if one is about to do a quickfix or not is also too simple minded.
You can easily turn your quickfixes/ branch into something else:
cd quickfixes/
bzr unbind # Make this a regular branch
cd ..
mv quickfixes/ complex-fix-for-bug342
bzr branch trunk/ quickfixes # Recreate quickfixes/ branch
cd quickfixes/
bzr bind URL_TO_UPSTREAM/trunk
There are methods for translating the uncommitted changes from one
branch to another too, if you prefer to not having to recreate the
quickfixes/ branch:
bzr branch trunk/ complex-fix-for-bug342
cd complex-fix-for-bug342
bzr merge --uncommitted ../quickfixes
cd ../quickfixes
bzr revert
> Bzr feels very strange and uncomfortable. It is workable, but not
> smooth or elegant, just kind of icky.
IMO, for the case we are talking about, it works nicely.
--
Óscar
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-12 8:40 ` Óscar Fuentes
@ 2010-01-12 9:39 ` Jan Djärv
2010-01-12 9:48 ` Óscar Fuentes
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Jan Djärv @ 2010-01-12 9:39 UTC (permalink / raw
To: Óscar Fuentes; +Cc: emacs-devel
Óscar Fuentes skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>> Óscar Fuentes skrev:
>>
>>> There is something that I disagree with BzrForEmacsDevs: a quickfix that
>>> requires more than one commit or that spans so long in time to warrant a
>>> merge from upstream does not qualify as a quickfix for me.
>>>
>> This is too simple. There have been many times in the CVS days when I
>> tried to commit a change only to find out there was a conflict
>> (usually ChangeLog). So I always merge from upstream before committing
>> to upstream.
>
> That's what `bzr up' does on a bound branch or checkout.
Yes, but that is not in the quickfix branch. You must resolve and test
conflicts in the qucik fix branch. This can't be done in the trunk branch (as
per the Wiki) as we don't even compile there. You could just resolve
conflicts textually, but not testing it before comitting upstream is noting I
would do.
>>
>> What starts out as a (presumed) quickfix often turns in to a
>> week/month long fix. To assume that one can always beforehand descide
>> if one is about to do a quickfix or not is also too simple minded.
>
> You can easily turn your quickfixes/ branch into something else:
>
> cd quickfixes/
> bzr unbind # Make this a regular branch
> cd ..
> mv quickfixes/ complex-fix-for-bug342
> bzr branch trunk/ quickfixes # Recreate quickfixes/ branch
> cd quickfixes/
> bzr bind URL_TO_UPSTREAM/trunk
I wouldn't call that easy, but thanks for the info.
This is not how the Wiki says the quick fix branch should be created though,
the last bind isn't there.
>
> There are methods for translating the uncommitted changes from one
> branch to another too, if you prefer to not having to recreate the
> quickfixes/ branch:
>
> bzr branch trunk/ complex-fix-for-bug342
> cd complex-fix-for-bug342
> bzr merge --uncommitted ../quickfixes
> cd ../quickfixes
> bzr revert
>
It doesn't matter which way you do it, you still have to do make bootstrap
again, and that is where time goes.
>> Bzr feels very strange and uncomfortable. It is workable, but not
>> smooth or elegant, just kind of icky.
>
> IMO, for the case we are talking about, it works nicely.
>
On some definition of "nicely", sure.
Jan D.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-12 9:39 ` Jan Djärv
@ 2010-01-12 9:48 ` Óscar Fuentes
2010-01-12 19:41 ` Eli Zaretskii
2010-01-13 0:01 ` Juanma Barranquero
2 siblings, 0 replies; 29+ messages in thread
From: Óscar Fuentes @ 2010-01-12 9:48 UTC (permalink / raw
To: emacs-devel
Jan Djärv <jan.h.d@swipnet.se> writes:
> This is not how the Wiki says the quick fix branch should be created
> though, the last bind isn't there.
This subthread is not about the recommendations on the Wiki. It's about
an alternative to them specific for to the quickfixes/ case.
[snip]
--
Óscar
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-12 7:47 ` Jan Djärv
2010-01-12 8:40 ` Óscar Fuentes
@ 2010-01-12 19:35 ` Eli Zaretskii
1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2010-01-12 19:35 UTC (permalink / raw
To: Jan Djärv; +Cc: ofv, emacs-devel
> Date: Tue, 12 Jan 2010 08:47:02 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: emacs-devel@gnu.org
>
> To assume that one can always beforehand descide if one is about to do a
> quickfix or not is also too simple minded.
You don't need to decide in advance. Start in the trunk or in
quickfix, and if you later see that a separate branch is required,
then
bzr branch trunk fix-something
cd fix-something
bzr merge ../trunk --uncommitted
cd ../trunk
bzr revert
cd ../fix-something
[and hack in the `fix-something' branch]
This copies uncommitted changes from trunk to a newly created branch,
then reverts the trunk to its previous pristine state, before you
started your not-so-simple fix.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-12 9:39 ` Jan Djärv
2010-01-12 9:48 ` Óscar Fuentes
@ 2010-01-12 19:41 ` Eli Zaretskii
2010-01-13 7:24 ` Jan D.
2010-01-13 0:01 ` Juanma Barranquero
2 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2010-01-12 19:41 UTC (permalink / raw
To: Jan Djärv; +Cc: ofv, emacs-devel
> Date: Tue, 12 Jan 2010 10:39:44 +0100
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: emacs-devel@gnu.org
>
> you still have to do make bootstrap again, and that is where time
> goes.
??? On what OS? It takes about 20 minutes on MS-Windows (which is
indeed painful), but on GNU/Linux I'm done in 5.
Of course, that's not to say that one should bootstrap every hour, but
if you need to do it every now and then, when you decide that another
branch is in order...
Furthermore, there are Bazaar tricks to have co-located branches, in
which case you don't need to bootstrap at all.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-12 9:39 ` Jan Djärv
2010-01-12 9:48 ` Óscar Fuentes
2010-01-12 19:41 ` Eli Zaretskii
@ 2010-01-13 0:01 ` Juanma Barranquero
2010-01-13 2:18 ` Stephen J. Turnbull
2 siblings, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-13 0:01 UTC (permalink / raw
To: Jan Djärv; +Cc: Óscar Fuentes, emacs-devel
On Tue, Jan 12, 2010 at 10:39, Jan Djärv <jan.h.d@swipnet.se> wrote:
> This can't be done in the trunk branch
> (as per the Wiki) as we don't even compile there.
FWIW, there's no intrinsic problem in building trunk; that it is not
recommended in the introductory document just means that it is added
complexity not deemed necessary for beginners, but of course you can
do it if you know what you're doing...
That said, as Eli has commented, bootstrapping is generally not *that*
painful, and you can use the checkout/switch method that Óscar
explained a while ago to have (sort of) colocated branches and avoid
most bootstrappings.
Juanma
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 2:18 ` Stephen J. Turnbull
@ 2010-01-13 2:16 ` Juanma Barranquero
2010-01-13 3:23 ` Stephen J. Turnbull
2010-01-13 2:27 ` Karl Fogel
1 sibling, 1 reply; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-13 2:16 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: Óscar Fuentes, Jan Djärv, emacs-devel
On Wed, Jan 13, 2010 at 03:18, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> But this isn't about "general", it's about a workflow where "bzr
> merge" is considered too painful.
Not bzr merge, but make bootstrap (so, in fact, is "bzr branch trunk
taskbranch" which is considered painful). And some of the alternatives
to having to bootstrap every branch have been already discussed.
Juanma
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 0:01 ` Juanma Barranquero
@ 2010-01-13 2:18 ` Stephen J. Turnbull
2010-01-13 2:16 ` Juanma Barranquero
2010-01-13 2:27 ` Karl Fogel
0 siblings, 2 replies; 29+ messages in thread
From: Stephen J. Turnbull @ 2010-01-13 2:18 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Óscar Fuentes, Jan Djärv, emacs-devel
Juanma Barranquero writes:
> On Tue, Jan 12, 2010 at 10:39, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
> > This can't be done in the trunk branch
> > (as per the Wiki) as we don't even compile there.
>
> FWIW, there's no intrinsic problem in building trunk; that it is not
> recommended in the introductory document just means that it is added
> complexity not deemed necessary for beginners,
As far as I know, it's not complex one way or the other, although I
have been a vpath addict for over a decade, so I have no experience.
The only thing you need to be careful about is that *all* build
products are in .bzrignore, and that you don't accidentally add any
scratch files you personally create, since the recommended workflows
do most pushing from there.
FWIW, the real reason that we didn't say anything about it is that the
original idea was that the trunk would be treeless, but it turns out
that you can't merge a branch without a tree. (It's not impossible in
theory -- eg, if the divergent changes affect different files -- but
bzr won't do it.)
> That said, as Eli has commented, bootstrapping is generally not *that*
> painful,
But this isn't about "general", it's about a workflow where "bzr
merge" is considered too painful.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 2:18 ` Stephen J. Turnbull
2010-01-13 2:16 ` Juanma Barranquero
@ 2010-01-13 2:27 ` Karl Fogel
2010-01-13 4:02 ` Stephen J. Turnbull
` (2 more replies)
1 sibling, 3 replies; 29+ messages in thread
From: Karl Fogel @ 2010-01-13 2:27 UTC (permalink / raw
To: Stephen J. Turnbull
Cc: Óscar Fuentes, Juanma Barranquero, Jan Djärv,
emacs-devel
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>FWIW, the real reason that we didn't say anything about it is that the
>original idea was that the trunk would be treeless, but it turns out
>that you can't merge a branch without a tree. (It's not impossible in
>theory -- eg, if the divergent changes affect different files -- but
>bzr won't do it.)
I think it was that, and a desire not to throw too many different ways
of doing things at newbies.
But at this point, I think we could update the BzrForEmacsDevs doc to
recommend just doing trivial mods in trunk and committing directly from
there. Heck, that's what I'm doing with really simple stuff.
Can anyone think of any gotchas? Particularly gotchas that would lead
to people on this list having to provide more support not less? :-)
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 2:16 ` Juanma Barranquero
@ 2010-01-13 3:23 ` Stephen J. Turnbull
2010-01-13 3:29 ` Lennart Borgman
2010-01-13 3:53 ` Juanma Barranquero
0 siblings, 2 replies; 29+ messages in thread
From: Stephen J. Turnbull @ 2010-01-13 3:23 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Óscar Fuentes, Jan Djärv, emacs-devel
Juanma Barranquero writes:
> On Wed, Jan 13, 2010 at 03:18, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
> > But this isn't about "general", it's about a workflow where "bzr
> > merge" is considered too painful.
>
> Not bzr merge, but make bootstrap
No, I really meant "bzr merge". AIUI people were discussing the
quickfixes branch, not feature branches. The claim has been that
spending 15 seconds (in most cases) making a trivial merge to trunk
before pushing is too annoying. If that's unacceptable, even five
minutes spent on an unnecessary bootstrap clearly would be too.
(Aside: the emphasis in recent threads on the importance of
streamlining the quickfixes workflow scares me.)
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 3:23 ` Stephen J. Turnbull
@ 2010-01-13 3:29 ` Lennart Borgman
2010-01-13 4:18 ` Eli Zaretskii
2010-01-13 3:53 ` Juanma Barranquero
1 sibling, 1 reply; 29+ messages in thread
From: Lennart Borgman @ 2010-01-13 3:29 UTC (permalink / raw
To: Stephen J. Turnbull
Cc: Óscar Fuentes, Juanma Barranquero, Jan Djärv,
emacs-devel
On Wed, Jan 13, 2010 at 4:23 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Juanma Barranquero writes:
> > On Wed, Jan 13, 2010 at 03:18, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> >
> > > But this isn't about "general", it's about a workflow where "bzr
> > > merge" is considered too painful.
> >
> > Not bzr merge, but make bootstrap
>
> No, I really meant "bzr merge". AIUI people were discussing the
> quickfixes branch, not feature branches. The claim has been that
> spending 15 seconds (in most cases) making a trivial merge to trunk
> before pushing is too annoying. If that's unacceptable, even five
> minutes spent on an unnecessary bootstrap clearly would be too.
>
> (Aside: the emphasis in recent threads on the importance of
> streamlining the quickfixes workflow scares me.)
It would be very good if someone pointed out on the wiki page where
(and perhaps how) you build Emacs. Do you do that in the trunk
directory, or? Is there anything special to consider?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 3:23 ` Stephen J. Turnbull
2010-01-13 3:29 ` Lennart Borgman
@ 2010-01-13 3:53 ` Juanma Barranquero
1 sibling, 0 replies; 29+ messages in thread
From: Juanma Barranquero @ 2010-01-13 3:53 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: Óscar Fuentes, Jan Djärv, emacs-devel
On Wed, Jan 13, 2010 at 04:23, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> No, I really meant "bzr merge". AIUI people were discussing the
> quickfixes branch, not feature branches. The claim has been that
> spending 15 seconds (in most cases) making a trivial merge to trunk
> before pushing is too annoying.
Well, what I was answering was the comment that having to bootstrap was onerous.
> (Aside: the emphasis in recent threads on the importance of
> streamlining the quickfixes workflow scares me.)
Me too, because I think it leads to everything done on trunk.
Juanma
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 2:27 ` Karl Fogel
@ 2010-01-13 4:02 ` Stephen J. Turnbull
2010-01-13 4:20 ` Eli Zaretskii
2010-01-13 16:55 ` Karl Fogel
2010-01-13 4:17 ` Eli Zaretskii
2010-01-13 8:31 ` Óscar Fuentes
2 siblings, 2 replies; 29+ messages in thread
From: Stephen J. Turnbull @ 2010-01-13 4:02 UTC (permalink / raw
To: Karl Fogel
Cc: Óscar Fuentes, Juanma Barranquero, Jan Djärv,
emacs-devel
Karl Fogel writes:
> But at this point, I think we could update the BzrForEmacsDevs doc to
> recommend just doing trivial mods in trunk and committing directly from
> there. Heck, that's what I'm doing with really simple stuff.
>
> Can anyone think of any gotchas? Particularly gotchas that would lead
> to people on this list having to provide more support not less? :-)
No. I just really dislike that workflow, personally. (I accumulate
typo fixes and the like separately -- what's the rush? -- and don't
trust even the simplest code change to be correct without testing, at
least a compile, link, re-byte-compile, run test suite -- so my
quickfixes are batched, too.) But that's a personal bias that I was
aware of, and I hope I mostly accounted for.
What consciously bothered me was experience with Mercurial. In
Mercurial, commit-to-trunk leads to a very confusing DAG as myriads of
no-see-um branches get created, often in parallel, then very quickly
merged. Unfortunately, they are very visible in the logs and in the
hgk DAG viewer (they're called "merge turds", which is quite apt), and
make use of hg diff confusing, too.
But in Bazaar with trunk bound to the public repo, that won't happen.
I didn't realize how powerful that technique would be. I still don't
like it myself, but now I have convinced myself that it won't cause
any issues for other developers. So I do not oppose including it
in BzrForEmacsDevs.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 2:27 ` Karl Fogel
2010-01-13 4:02 ` Stephen J. Turnbull
@ 2010-01-13 4:17 ` Eli Zaretskii
2010-01-13 8:31 ` Óscar Fuentes
2 siblings, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2010-01-13 4:17 UTC (permalink / raw
To: Karl Fogel; +Cc: ofv, lekktu, stephen, jan.h.d, emacs-devel
> From: Karl Fogel <kfogel@red-bean.com>
> Date: Tue, 12 Jan 2010 21:27:42 -0500
> Cc: Óscar Fuentes <ofv@wanadoo.es>,
> Juanma Barranquero <lekktu@gmail.com>,
> Jan Djärv <jan.h.d@swipnet.se>, emacs-devel@gnu.org
>
> But at this point, I think we could update the BzrForEmacsDevs doc to
> recommend just doing trivial mods in trunk and committing directly from
> there. Heck, that's what I'm doing with really simple stuff.
>
> Can anyone think of any gotchas?
If there are any gotchas, I have yet to see them. I've been doing
this since day one.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 3:29 ` Lennart Borgman
@ 2010-01-13 4:18 ` Eli Zaretskii
2010-01-13 4:56 ` Lennart Borgman
0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2010-01-13 4:18 UTC (permalink / raw
To: Lennart Borgman; +Cc: ofv, lekktu, stephen, jan.h.d, emacs-devel
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Wed, 13 Jan 2010 04:29:51 +0100
>
> It would be very good if someone pointed out on the wiki page where
> (and perhaps how) you build Emacs. Do you do that in the trunk
> directory
Yes.
> Is there anything special to consider?
No. Just do it as usual.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 4:02 ` Stephen J. Turnbull
@ 2010-01-13 4:20 ` Eli Zaretskii
2010-01-13 16:55 ` Karl Fogel
1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2010-01-13 4:20 UTC (permalink / raw
To: Stephen J. Turnbull; +Cc: kfogel, ofv, jan.h.d, emacs-devel, lekktu
> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 13 Jan 2010 13:02:37 +0900
>
> No. I just really dislike that workflow, personally. (I accumulate
> typo fixes and the like separately -- what's the rush? -- and don't
> trust even the simplest code change to be correct without testing, at
> least a compile, link, re-byte-compile, run test suite -- so my
> quickfixes are batched, too.) But that's a personal bias that I was
> aware of, and I hope I mostly accounted for.
Testing before committing is (or should be) good practice, not just
personal bias. I always at least rebuild Emacs, even if it's just a
typo in a comment, before committing. I was doing that with CVS as
well. There's nothing more embarrassing than botching the build by
committing untested changes.
> But in Bazaar with trunk bound to the public repo, that won't happen.
> I didn't realize how powerful that technique would be. I still don't
> like it myself, but now I have convinced myself that it won't cause
> any issues for other developers. So I do not oppose including it
> in BzrForEmacsDevs.
Yes, I think we should do that. I'm doing all my quick-fixing stuff
in the trunk directly.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 4:18 ` Eli Zaretskii
@ 2010-01-13 4:56 ` Lennart Borgman
2010-01-13 8:48 ` Stephen J. Turnbull
0 siblings, 1 reply; 29+ messages in thread
From: Lennart Borgman @ 2010-01-13 4:56 UTC (permalink / raw
To: Eli Zaretskii; +Cc: ofv, lekktu, stephen, jan.h.d, emacs-devel
On Wed, Jan 13, 2010 at 5:18 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Wed, 13 Jan 2010 04:29:51 +0100
>>
>> It would be very good if someone pointed out on the wiki page where
>> (and perhaps how) you build Emacs. Do you do that in the trunk
>> directory
>
> Yes.
>
>> Is there anything special to consider?
>
> No. Just do it as usual.
Thanks Eli.
Maybe it should be pointed out somewhere? I am not sure.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-12 19:41 ` Eli Zaretskii
@ 2010-01-13 7:24 ` Jan D.
0 siblings, 0 replies; 29+ messages in thread
From: Jan D. @ 2010-01-13 7:24 UTC (permalink / raw
To: Eli Zaretskii; +Cc: ofv, emacs-devel
On 2010-01-12 20:41, Eli Zaretskii wrote:
>> Date: Tue, 12 Jan 2010 10:39:44 +0100
>> From: Jan Djärv<jan.h.d@swipnet.se>
>> Cc: emacs-devel@gnu.org
>>
>> you still have to do make bootstrap again, and that is where time
>> goes.
>
> ??? On what OS? It takes about 20 minutes on MS-Windows (which is
> indeed painful), but on GNU/Linux I'm done in 5.
Takes about 10-15 minutes for me on GNU/Linux. My machine is a couple
of generations old.
>
> Of course, that's not to say that one should bootstrap every hour, but
> if you need to do it every now and then, when you decide that another
> branch is in order...
>
> Furthermore, there are Bazaar tricks to have co-located branches, in
> which case you don't need to bootstrap at all.
I'll have to read up on those, sounds useful.
Jan D.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 2:27 ` Karl Fogel
2010-01-13 4:02 ` Stephen J. Turnbull
2010-01-13 4:17 ` Eli Zaretskii
@ 2010-01-13 8:31 ` Óscar Fuentes
2 siblings, 0 replies; 29+ messages in thread
From: Óscar Fuentes @ 2010-01-13 8:31 UTC (permalink / raw
To: emacs-devel
Karl Fogel <kfogel@red-bean.com> writes:
> But at this point, I think we could update the BzrForEmacsDevs doc to
> recommend just doing trivial mods in trunk and committing directly from
> there. Heck, that's what I'm doing with really simple stuff.
>
> Can anyone think of any gotchas? Particularly gotchas that would lead
> to people on this list having to provide more support not less? :-)
Personally, I prefer the conceptual simplicity of using trunk/ as the
gateway to upstream and do not overload it with other uses. It costs
nothing to bind quickfixes/ to upstream as trunk/ already is. I think
that if people use trunk/ for hacking, eventually it will get polluted
by half done quickfixes and will inhibit the use of feature branches
(because you need to clean up trunk/ before merging the feature branch
into upstream, etc), thus involuntarily encouraging a disorganized
personal development model, as was the case with CVS.
--
Óscar
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 4:56 ` Lennart Borgman
@ 2010-01-13 8:48 ` Stephen J. Turnbull
0 siblings, 0 replies; 29+ messages in thread
From: Stephen J. Turnbull @ 2010-01-13 8:48 UTC (permalink / raw
To: Lennart Borgman; +Cc: ofv, lekktu, Eli Zaretskii, jan.h.d, emacs-devel
Lennart Borgman writes:
> >> It would be very good if someone pointed out on the wiki page where
> >> (and perhaps how) you build Emacs. Do you do that in the trunk
> >> directory
> >
> > Yes.
> >
> >> Is there anything special to consider?
> >
> > No. Just do it as usual.
>
> Thanks Eli.
>
> Maybe it should be pointed out somewhere? I am not sure.
I don't think so. There should not be any problems related to
building, *except* that the workflow common in "small" projects of
using "bzr branch" a lot without a shared repository should be avoided
in Emacs because the overhead of "make bootstrap" is noticable, and
unnecessary with an appropriate workflow.
I think you're the first person I've seen to worry about it, so I
don't think it's a FAQ. When EmacsForBzrDevs is updated, we can just
add "You can just build and test as usual in the 'trunk' branch if you
use it for quick fixes."
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: bzr workflow
2010-01-13 4:02 ` Stephen J. Turnbull
2010-01-13 4:20 ` Eli Zaretskii
@ 2010-01-13 16:55 ` Karl Fogel
1 sibling, 0 replies; 29+ messages in thread
From: Karl Fogel @ 2010-01-13 16:55 UTC (permalink / raw
To: Stephen J. Turnbull
Cc: Óscar Fuentes, Juanma Barranquero, Jan Djärv,
emacs-devel
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>But in Bazaar with trunk bound to the public repo, that won't happen.
>I didn't realize how powerful that technique would be. I still don't
>like it myself, but now I have convinced myself that it won't cause
>any issues for other developers. So I do not oppose including it
>in BzrForEmacsDevs.
I've revamped http://www.emacswiki.org/emacs/BzrForEmacsDevs
accordingly. Review and edits welcome.
-Karl
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2010-01-13 16:55 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-11 21:10 bzr workflow Sam Steingold
2010-01-11 21:35 ` Andreas Schwab
2010-01-11 21:57 ` Sam Steingold
2010-01-11 23:05 ` Andreas Schwab
2010-01-11 21:37 ` Óscar Fuentes
2010-01-11 22:13 ` Chong Yidong
2010-01-12 7:47 ` Jan Djärv
2010-01-12 8:40 ` Óscar Fuentes
2010-01-12 9:39 ` Jan Djärv
2010-01-12 9:48 ` Óscar Fuentes
2010-01-12 19:41 ` Eli Zaretskii
2010-01-13 7:24 ` Jan D.
2010-01-13 0:01 ` Juanma Barranquero
2010-01-13 2:18 ` Stephen J. Turnbull
2010-01-13 2:16 ` Juanma Barranquero
2010-01-13 3:23 ` Stephen J. Turnbull
2010-01-13 3:29 ` Lennart Borgman
2010-01-13 4:18 ` Eli Zaretskii
2010-01-13 4:56 ` Lennart Borgman
2010-01-13 8:48 ` Stephen J. Turnbull
2010-01-13 3:53 ` Juanma Barranquero
2010-01-13 2:27 ` Karl Fogel
2010-01-13 4:02 ` Stephen J. Turnbull
2010-01-13 4:20 ` Eli Zaretskii
2010-01-13 16:55 ` Karl Fogel
2010-01-13 4:17 ` Eli Zaretskii
2010-01-13 8:31 ` Óscar Fuentes
2010-01-12 19:35 ` Eli Zaretskii
2010-01-11 22:08 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.