On Sun, Oct 20, 2013 at 12:59:21AM -0700, Blake McBride wrote:
> Not sure what you mean about designed well, but in order to switch
> branches without having to do a full rebuild would involve:
> 1.  switching branches would have to auto-delete compiled modules
>     (object files) for source files that aren't contained in the new
>     branch in order to avoid link time collisions.  Or, your build
>     process would have to detect left over object files from a
>     branch switch and delete them at build time.

Why?  Isn't a switch from one branch to another basically the same as
making changes in several files in between builds?

Why do you need to remove the now unused object files?  Surely you
don't link by using wildcards so the unused object files will simply
not get linked in to the final result.  Of course incremental linking
won't be possible but triggering a full re-link on switching branches
would offer a rather cheap solution to that.

> 2.  from one branch to another there may be an include file (when
>     using C/C++) that has a difference possibly necessitating a full
>     rebuild.

Indeed, and again that should be handled exactly the same way as a
manual change in that header file in between builds on a branch.

> 3.  git would have to restore files using the current date and time
>     (as opposed to their original date/time) in order for the build
>     system to force a recompile on those modules (I checked - git
>     does do this!)


> I am sure there are many other possible system-specific issues as
> well, i.e. many situations where switching branches would subtly
> necessitate a full rebuild.   They would present themselves as very
> hard-to-find bugs that would disappear when a full rebuild occurred.

Strictly speaking any such thing would be a bug in your build system,
e.g. incomplete dependency information.

> I can't imagine how any SCMS could solve problems like these.
> (Although, I ask the question in case there is a solution that
> eludes me.)  Without a solution to problems like these, given a very
> large system, many of the cool features of a SCMS are not of much
> use.

I think you imagine correctly.  These problems don't fall within the
purview of a VCS (git is a VCS, not an SCMS).

> I bring all this up not to be difficult.  I read about many cool
> SCMS features, but I can't see how they could be useful in a very
> large environment that I use all the time.  I am wondering if there
> is a solution I am unaware of.  Thinking about it, I suppose there
> are some design decisions that could be employed that are driven by
> nothing more than an attempt to resolve SCM branch issues, but there
> is no way I am aware of to totally fix the fundamental problems.

Well, many of the issues you mention can be solved by using a build
system that can take advantage of a shared cache of build objects.
Connect a CI system that builds each branch regularly and you can
largely get around those large local re-builds.


Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe               http://therning.org/magnus

As far as the laws of mathematics refer to reality, they are not
certain, and as far as they are certain, they do not refer to reality.
     -- Albert Einstein

Attachment: pgpbjf37nYUed.pgp
Description: PGP signature

Reply via email to