Re: bzr repository ready?

[Eli Zaretskii]

> From: Óscar_Fuentes <address@hidden>
> Cc: address@hidden
> Date: Sat, 21 Nov 2009 21:17:01 +0100
> 
> Eli Zaretskii <address@hidden> 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.

Of course.  But building does not take a lot of time, except for the
first time, which does a full bootstrap for that branch.

> 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?

It's a CVS checkout of the trunk, with local changes.  Each "cvs up"
merges the changes on the trunk with my local changes.  Since no one
is working on the display engine, I had maybe one or two conflicts in
several months.  It's really not such a big deal, even with CVS.  I
don't see how any VCS could "shine" in this use-case.  Maybe I'm
missing something.