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 <blake1...@gmail.com> 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 
>>> masterwould 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+unsubscr...@googlegroups.com.
> 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.

Reply via email to