Re: patch vs. overwrite in bzr

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 07 Apr 2012 04:28:46 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [snip]
> 
> > FWIW, I like having separate branches.  At least for Emacs, and for
> > the use case when the changes in the branch are significant (like what
> > I had for bidi), co-located branches get in the way because switching
> > branches needs to make a lot of changes, and requires a large build if
> > not a full bootstrap.
> 
> Use out-of-source builds, with a build directory per branch...

What for?  I have no problems with the above arrangement.  Joakim
asked how others arrange their branches, and I described mine.  There
are no problems I have that would require me to change it.

> unless that collides with Emacs' peculiar practice of putting build
> products on the source tree for out-of-source builds.

Nothing peculiar here: the Windows build simply doesn't support
out-of-source builds.  But I build inside the source tree on GNU/Linux
as well, so that's not the main reason.

> On addition, when I switch branches from Emacs the relevant function is
> advised for storing timestamps of the files of the current branch before
> the switch and recover the timestamps of the new branch's files after
> the switch, so no rebuild is triggered because some source file was
> modified by the switch when the new branch already has an associated up
> to date build.

IMO, this is a dangerous practice, because you cannot always
second-guess what needs to be rebuilt after the switch, what with all
the complex Makefile rules.

In any case, if you have branches in separate directories, you get
that for free.

> vc-git solves this by displaying the current branch name on the
> modeline. vc-bzr could do the same if colocated branches gain
> popularity.

You are assuming that I use VC to do my bzr operations.  That's false.