emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bzr repository ready?


From: Stephen J. Turnbull
Subject: Re: bzr repository ready?
Date: Tue, 24 Nov 2009 18:35:10 +0900

Eli Zaretskii writes:

 > I'm not sure I understand this.  With the commands described on the
 > wiki, my understanding is that the history is in the `trunk' branch,
 > which is a mirror of (some) branches in the master repository, while
 > the source tree is in the development branches.  Is that true?

No.  The history of the project is not just the names, dates, and log
messages for versions.  It also includes the contents of the files that
make up each version, either as a copy of the file, or as a sequence
of diffs against some base version.  Since history is shared among
branches, the first branch is going to bring all the shared history,
plus a little bit of history that's specific to it.  This is
regardless of whether a source tree is checked out or not.

 >   Bazaar allows all the branches in the repository to share storage,
 >   which makes the branches much more lightweight than CVS branches.
 >   However, it still takes time to checkout the source tree for each
 >   branch, and bootstrapping a new tree is annoyingly long.  That is
 >   why we recommend that for small changes you keep reusing the same
 >   ``quickfixes'' branch.  This way, once you bootstrapped the
 >   ``quickfixes'' branch once, the subsequent update, build, and commit
 >   steps of the update-edit-build-test-commit cycle will all be very
 >   fast, as long as you continue working in the same branch.

That's better than what I had.

 > >  > (Release branches will need that, right?)
 > > 
 > > Yes, but AIUI people who create release branches are not the target
 > > audience of this document.
 > 
 > I thought the document targets maintainers as well.  Me, for example.

It targets maintainers to the extent that they're ordinary developers,
yes, but it seems likely to me that maintainers will be using
techniques that ordinary developers don't need to know about.  Like
creating release branches.  And they will need somewhat deeper
knowledge than the very superficial "do it this way at first and life
will start out good and only get better as you learn more" way this
document is written.

The way I think about this document, creating release branches is rare
enough and important enough that whoever does it can ask for help when
the time comes if they need it.  And I'm sure they'll get it,
immediately.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]