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. /M -- 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
pgpdsG86AAVnR.pgp
Description: PGP signature
