On Mon, Dec 09, 2013 at 12:35:38PM -0800, Junio C Hamano wrote:
> Dominik Vogt <vogt@xxxxxxxxxxxxxxxxxx> writes:
>
> > Me and some colleagues work on gcc in lots of different branches.
> > For each branch there is a separate build directory for each
> > branch, e.g. build-a, build-b and build-c. Let's assume that all
> > branches are identical at the moment. If a file in branch a is
> > changed that triggers a complete rebuild of gcc (e.g.
> > <target>.opt), rebuilding in build-a takes about an hour. Now,
> > when I switch to one of the other branches, said file is not
> > identical anymore and stamped with the _current_ time during
> > checkout. Although branch b and c have not changed at all, they
> > will now be rebuilt completely because the timestamp on that files
> > has changed.
>
> I am not quite sure I follow your set-up. Do you have three working
> trees connected to a repository (via contrib/workdir/git-new-workdir
> perhaps), each having a checkout of its own branch?
No, just one working tree, but three separate build directories
for various branches. Actually, the build directories could be
located at some random place on disk, but it's convenient to keep
them inside the working tree. Personally I do not use multiple
working trees because in the past I had the impression that this
kind of setup creates more problems than it solves. Just to give
you an idea how my current workspace looks like:
~/rpm/BUILD/gcc-4.1.2-20080825
build-4.1/
install-4.1/
...
(branch "master")
~/rpm/BUILD/gcc-4.4.7-20120601
build-4.4/
install-4.1/
(branch "master")
~/src/git/gcc-unpatched
build/
install/
...
(branch "master")
~/src/git/gcc-patched
build-4.8/
build-4.9/
build-somefeature/
install-4.8/
install-4.9/
install-somefeature/
...
(various feature branches)
> [snip]
Hm, the case I described was too simple. Another try:
* With the setup described above I have, say, eleven branches, namely
a and b, b2, ..., b9:
---o---X <== a
|
`---Y <== b
|
|---o <== b2
...
`---o <== b9
* The two commits X and Y both touch a file that triggers a
complete rebuild, say gcc/common.opt.
* Each branch has a matching build directory build-<branch>, and
all of them are built for the latest version of the
corresponding branch.
* Switch to branch a and do some work or just look at it.
* When I switch back to any of the b-branches, gcc/common.opt gets
stamped with the current time, i.e. "make" considers the whole
build directory to be outdated and builds everything from
scratch. Then I switch to another b-branch and the whole thing
starts over etc. With gcc-bootstrapping enabled, such a build
takes me almost an hour. In other words, just looking at branch
a entails a full day just rebuilding branches that have not
changed at all.
I've discussed that with some of my co-workers, but we still
could not come up with a nice solution. The "right" way to "fix"
this might be to stash all file modification dates on a branch
switch and restore them when switching back to the original. But
that sounds awfully expensive, and really out of the scope of an
RCS. The second best approach I could think of is to stamp files
with the timestamp of the last commit that touched that, but I
guess that is not a cheap operation either.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html