From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Craig L. Ching" <cching@mqsoftware.com>
Cc: sverre@rabbelier.nl, Git Mailinglist <git@vger.kernel.org>
Subject: Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
Date: Thu, 31 Jul 2008 14:40:55 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0807311426090.3277@nehalem.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org>
On Thu, 31 Jul 2008, Linus Torvalds wrote:
>
> Sure, if you want to keep the build tree around, you would probably not
> use branches.
Side note: it's often faster to recompile, if your project has a good
build system.
For example, for the kernel, I can literally rebuild my whole kernel
(which is just what I use on _that_ machine) in about 16 seconds. This is
_not_ using ccache or anything else - it's rebuilding the whole tree with
-j16.
It turns out that using multiple build trees would actually slow things
down, because then the source code wouldn't fit in memory any more. If I
have to actually read the source code from the disk, my nice 16-second
compile goes up to a minute or more.
Now, the thing you should take away from this is:
- kernel people have cool toys, and CPU's that are faster than what you
have. Nyaah, nyaah.
- disk is slow. REALLY slow. If you can share most of a single source
tree and thus keep it in memory, you're ahead.
- even large projects can have a fast build cycle if your build chain
doesn't suck. The kernel is larger than most, but a _lot_ of build
systems don't parallelize or use horribly inefficient tools, so they
take much longer to build.
The last part is the thing that people often stumble on. For example, I
can literally compile the kernel a hell of a lot faster than I can do
"make doc" on the git tree! Even just trying a "make -j16" when building
the git documentation is really really really painful. I suspect I'd need
a ton more memory for that horror.
So if your workflow involves xml (I think the doc build for git is all
xsltproc - along with asciidoc written in python or something), you're
screwed. But in the kernel we've actually cared pretty deeply about build
times, and as a result it's actually very pleasant to switch branches and
just rebuild. Even if some core header file has changed, it's _still_ ok
if you've got enough CPU.
(I just tested - I can do a "make doc" for git in just under a minute from
a clean tree. Ouch. That really is three times longer than my kernel
build - as long as I brought the kernel and compiler into memory first ;)
Linus
next prev parent reply other threads:[~2008-07-31 21:52 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-31 18:13 Git vs Monotone Sverre Rabbelier
2008-07-31 18:33 ` Stephen R. van den Berg
2008-07-31 18:52 ` Petr Baudis
2008-07-31 19:02 ` Jeff King
2008-07-31 19:11 ` Craig L. Ching
2008-07-31 19:19 ` Sverre Rabbelier
2008-07-31 20:32 ` Jeff King
2008-07-31 19:17 ` Linus Torvalds
2008-07-31 19:28 ` Craig L. Ching
2008-07-31 19:52 ` Linus Torvalds
2008-07-31 20:24 ` Junio C Hamano
2008-07-31 20:30 ` Linus Torvalds
2008-08-23 19:23 ` Felipe Contreras
2008-07-31 20:42 ` Blum, Robert
2008-08-10 22:15 ` Robin Rosenberg
2008-08-01 9:57 ` David Kastrup
2008-07-31 19:48 ` Monotone workflow compared to Git workflow ( was RE: Git vs Monotone) Craig L. Ching
2008-07-31 20:09 ` Linus Torvalds
2008-07-31 20:18 ` Shawn O. Pearce
2008-07-31 20:37 ` Craig L. Ching
2008-07-31 20:54 ` Björn Steinbrink
2008-07-31 21:10 ` Avery Pennarun
2008-07-31 21:13 ` Linus Torvalds
2008-07-31 21:43 ` Martin Langhoff
2008-07-31 21:40 ` Linus Torvalds [this message]
2008-08-01 2:50 ` Dmitry Torokhov
2008-08-01 3:02 ` Linus Torvalds
2008-08-01 3:59 ` Linus Torvalds
2008-07-31 20:57 ` Sean Estabrooks
2008-07-31 21:22 ` Theodore Tso
2008-07-31 19:24 ` Git vs Monotone Theodore Tso
2008-08-01 7:23 ` Sverre Rabbelier
2008-08-01 18:00 ` Daniel Barkalow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.1.10.0807311426090.3277@nehalem.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=cching@mqsoftware.com \
--cc=git@vger.kernel.org \
--cc=sverre@rabbelier.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).