Re: bzr repository ready?

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

>> For large compiled projects such as Emacs, the use of feature branches
>> is not that great. First, building takes a long time.
>
> Why does the building take a long time in that case?
>
>> Second, it imposes a large penalty on those who just want to hack
>> some elisp.
>
> What penalty is that?

Let's suppose that you want to do some lightweight hacking on a elisp
component of emacs. The `feature branch' workflow says that you create a
new local branch specifically for that:

bzr branch path/to/my/local/emacs/mirror fix-bug-3429

and then you edit the .el files. But at some point you want to test
them, and for that you need an emacs executable. Now, building emacs is
not a fast operation even on a GNU/Linux modern desktop (let's not
mention Windows). Hence, even when you start the build right after the
feature branch creation, it is possible that you end your modifications
before the build ends. This certainly will occur often on slow GNU/Linux
machines and even on fast Windows machines.

Maybe emacs has a mechanism for executing it using a uncompiled elisp
source tree that resides on other directory. If that is the case, you
could use a pre-existent emacs executable for testing your changes.

>> Maybe a system based on `bzr switch' is the solution for Emacs,
>> although it is not so simple to understand as feature branches. For
>> the diehard CVS users, beginning with a single work branch is the
>> solution. `bzr shelve' would help them
>
> I'd appreciate some more details on that.  It's hard to make up your
> mind about the usage patterns with so many new factors being
> introduced in ever sentence without any explanations.  (And yes, I did
> read the Bazaar User Reference for these two commands, but it's just
> awful: "bzr shelve" does not describe its argument FILE, "bzr switch"
> does not tell what is its argument TO_LOCATION, etc.  The User Guide
> helps a bit, but you cannot search in it, at least not in the on-line
> version.)

I guess that this is yet another case of "having lots of options is
counter-producing for the uninformed".

I was thinking on writing an incremental guide for those who know
nothing about DVCSs and bzr in particular, beginning with the most
simple workflows and evolving step by step to the sophisticated ones,
explaining the advantages that each level brings over the previous
one. This way each hacker could choose his own workflow basing the
decission on some solid info. But my English is awful. If I could write
on Spanish and some volunteer translate it to English...

-- 
Óscar