Preventing a complete rebuild using branches with GIT and Visual Studio 2005

Question

One of the problem I faced when using branches in GIT was that it was very easy when switching branches to cause visual studio 2005 to cause a complete rebuild of the source because of the time/date being changed when switching branches.

My typical layout is this.
svn/remote
master
test

When switch between either the test and the master branch even though both of them shared exactly the same timestamp on the project. It would cause visual studio 2005 to rebuild the complete project again.

To resolve this issue, my solution was to create another GIT repository but to make a new repository that pulled from the main repository c:/myPrimary 'test' branch. This way, even though both master and test branches had their own folder via the extra repository this resolved having to do a complete recompilation of the source code when switching between the two.

Just checking if anyone else have had this problem and the solution they have come up with resolving it. Please note, a complete recompilation of the source code is in the area of 20 minutes.

Answer 1

I wouldn't know about git, but since this has an SVN tag, too...

Using SVN, I always have multiple checkouts of several branches in parallel. Switching between them just means to switch to another VS session.

Oh, and look at IncrediBuild by Xoreax. You can download a test version to play with for 30 days. (Be aware, though: I've yet to see a C++ developer who's not addicted to it after those 30 days.) I have seen it cutting down the times for total rebuilds of a project from 60mins to 10mins, using up to 30 CPUs in the network, making changes in certain headers again feasible.

Answer 2

git only touches files which actually change when switching branches, so only translation units that include files that are different between the two branches should have their timestamp updated when switching between the two branches.

Visual Studio 2005 is generally very good at incremental builds, but it is very easy in C++ to build up overly inter-dependent include paths if you aren't careful to manage a project's complexity.

Have you tried analysing your source file dependencies to see if a set of frequently changed header files is causing a large subset of object files to be rebuilt?