Yes, of course, creating a totally new branch from where you are doesn't cause any problems because nothing changes.
The problem is that, I and likely most of the world, have a handful of long-running branches - that already exist. A full rebuild is out of the question when it takes two hours. I just took a look at GO. I previously thought it was Google's replacement of GWT. No, it's a language. These days all that matters are web apps. Anything else can be written in C/C++. In terms of parallel programming, there are some really good tools for C/C++ such as silk. Take care, Blake On Sunday, October 20, 2013 3:18:32 AM UTC-5, Wes Freeman wrote: > > When you create a branch, if you have already compiled object files, you > can keep them in your folder. You don't have to do a clean build on > creation of the branch. Then you can make your changes, do incremental > builds, and solve the problem/merge your code into the master. > > The problem lies in switching between branches that already exist, which > might force a clean build... > > As a side note, I'm really enjoying Go's ridiculously fast build times. > > Wes > > On Sun, Oct 20, 2013 at 3:59 AM, Blake McBride <blak...@gmail.com<javascript:> > > 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. >> >> 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. >> >> Thanks. >> Blake McBride >> >> >> >> >> On Saturday, October 19, 2013 5:52:00 PM UTC-5, Gergely Polonkai wrote: >> >>> Hello, >>> >>> 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. >>> >>> Cheers, >>> Gergely >>> On 19 Oct 2013 23:40, "Blake McBride" <blak...@gmail.com> wrote: >>> >>>> Greetings, >>>> >>>> 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 >>>> master would be stable (contain no partial commits). My problem is >>>> this. Given 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? >>>> >>>> Thanks. >>>> >>>> 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 email to git-users+...@**googlegroups.com. >>>> >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<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 to git-users+...@googlegroups.com <javascript:>. >> 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
