On Sun, Oct 20, 2013 at 11:05:30AM -0700, Blake McBride wrote:
> See inline comments below:
> On Sunday, October 20, 2013 12:34:32 PM UTC-5, Magnus Therning wrote:
>> 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? 
> Ahh, no.

It sure has been in every large system I've worked on.  It may be
different depending on programming language, I work mostly with C/C++,
but others like OCaml don't behave any different.  So exactly *what*
is different in your setup?  Why does this hit you so hard?

>> 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. 
> I have 15K classes.  Yes, 15 thousand.  It is a Java web app, and
> yea, it does use wildcards.
> If I switched branches, the .class files are left over from before
> the switch.  Sometimes having unnecessary .class files doesn't
> matter, sometimes it does!

Well, to be blunt to me it sounds like you're doing something wrong if
you have a single project with 15k classes.  All project I've worked
on have split into modules that are version controlled separately long
before that happens.  Then releases are controlled through a CMS that
works in concert with VCS.  To avoid large rebuilds we've then used
caches of object files.

Also, like I mentioned above you need to look at your *build system*
to remove superfluous files resulting from previous builds.  Your VCS
is unlikely to know how your source relates to your build results.

>>> 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. 
> You are missing the point.  I can't wait for a two hour build every
> time I switch projects.  If there was a real change to a header file
> necessitating a full rebuild I would do it one and be done.  I can't
> do it again and again every time I switch branches.

Well, then please explain the point so I understand.  To me it sounds
like you would like your VCS to somehow break a dependency between two
source files.  If you modify something that a large portion of your
sources depend on, like a config.h header file, well then Git won't be
able to magically break the dependencies on that header file.  What
you need to do then is structure your source differently!

>>> 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 think the problems I describe are non-issues in small to mid-sized
> projects.  The problems I describe only appear in very large
> projects.  You seem to have some idealistic view of how a very large
> and complex application can be cleanly structured so that the issues
> I describe would not occur.  

Oh no, unnecessary re-builds become a problem also in small projects,
they just don't hurt as much.  I've worked on systems that take 3-4
hours for a complete build, but through modularisation and caching of
build results any build rarely took more than 15 minutes.


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

Don't worry about other people stealing your ideas. If your ideas are
any good, you’ll have to ram them down people's throats.
     -- Howard Aiken, IBM Engineer

Attachment: pgpdsG86AAVnR.pgp
Description: PGP signature

Reply via email to