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.
>
> I'm not quite sure I understand.  Are you talking about bootstrap?
> That one indeed can take 30 minutes on Windows.  But that's a one-time
> thing; subsequent builds, when just a handful of files are modified
> are much faster.  It's a rare feature or even a bugfix that needs only
> one build. 

The newly created feature branch you are working on is a pristine set
of versioned files on a new directory. If you want to test your change,
you need to build the emacs executable, because it is not there.

> And its already clear that making a full-fledged branch for a simple
> bugfix is not the best idea.

IMO, yes, but other DVCS proponents will try to convince you that
creating feature branches even for simple changes is the Right
Thing. And that is true if your project doesn't require building before
testing.

[snip]

> Actually, I think I've understood enough to know what to do first when
> we switch to bzr.  About the only thing that's still not clear enough
> is whether to keep my bidi branch locally or on subversions.  Any
> thoughts?

Precisely DVCS shines on cases like yours: you have your own private
branch were you develop bidi and, besides synching with emacs' master
branch from time to time, you occasionally push your changes to a
publicly availabe mirror of your bidi branch, so people can follow your
development and hopefully test it and contribute patches.

DVCS makes this very easy, either using your own machine as the server
(a http server suffices for read-only access) or a service like
launchpad, which adds bug reporting, patch management, etc.

If you need help on figuring out how to do that, please ask. How do you
manage your bidi branch right now? Is it a CVS branch on the Emacs
repository or a set of patches that you store on your machine?

-- 
Óscar