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. > > 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! > > > 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. > > > 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 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. > > > 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). > Agreed. I suppose reading some of the hype about git, I wanted to investigate it. Git surely has a nice design. I'll likely make increasingly greater use of it - even if it doesn't provide me with scrambled eggs in the morning! > > > 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 <javascript:> jabber: > mag...@therning.org<javascript:> > 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 > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
