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!) Indeed. > 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. /M -- 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
pgpbjf37nYUed.pgp
Description: PGP signature
