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.
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.
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.
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 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.
On Saturday, October 19, 2013 5:52:00 PM UTC-5, Gergely Polonkai wrote:
> according to your description, your project seems to be something like the
> Linux kernel, and Git handles that just fine. Depending on your build
> environment, Git branches may help you a lot, as, if it is designed well,
> can prevent full rebuilds.
>> I have a large application that takes about two hours to build. Sometime
>> I have to do partial-project commits in order to communicate
>> development from one area to another (I can explain further but it is
>> irrelevant to the question). I'd prefer (if I was using git rather than
>> svn) to create a branch to commit the partial work, debug, and finally
>> merge to the master when it is all done. This way each commit on
>> masterwould be stable (contain no partial commits). My problem is this.
>> the size of the project, I can't checkout different versions without
>> causing a two hour build. I am sure this must be a common problem.
>> Stated another way - when you have a very large project, branching
>> becomes a significant problem because of build times. Are there common
>> solutions to this sort of problem?
>> Blake McBride
>> 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
>> For more options, visit https://groups.google.com/groups/opt_out.
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
For more options, visit https://groups.google.com/groups/opt_out.