Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-02-11 10:33:44

On 02/11/2012 03:48 PM, Julian Gonggrijp wrote:
> Thomas Heller wrote:
>
>> On 02/11/2012 01:42 PM, Julian Gonggrijp wrote:
>>
>>> So the perceived problem is that it would take too much time for the
>>> volunteers to check out all of the numerous feature branches that
>>> might exist at any given moment and test all of them, in addition to
>>> the develop branch and the current release branch. The practical
>>> consequence is that features under active development cannot be tested
>>> on all platforms until they're merged back into the develop branch.
>>>
>>> Here's why I think this isn't a real issue.
>>>
>>> [...]
>>
>> Right, that all makes sense. However, the whole branching stuff seems like a lot of overhead (even if the tool is able to handle it very good).
>
> Please take my word that the branching stuff doesn't add any overhead.
> Forks and merges are just special cases of commits:

> Commit - create a new commit with one previous commit as parent.
> Fork   - create a new commit which will have a sibling from the same
>           parent.
> Merge  - create a new commit with two parents.

You gotta be kidding me, right? Even with the most awesome tool in the 
world, it is trivial to see that this adds overhead! While by simply 
committing stuff, i just have to issue one command and be able to 
observer that everything still is alright.
You already listed forking and merging as two different steps!
Come on ...

> That's all there is to branching in git. History is a directed acyclic
> graph of commits with parent relationships. Under the hood, a branch
> is nothing more than a bookmark to a leaf commit.

Yeah, this all sounds very nifty ... in theory. This all means overhead 
in terms of commands to issue and quality assurance that everything went 
right, including running tests after the merge (did it really merge 
everything correctly), resolving possible conflicts etc.
While I admit that all this branching sounds very tempting, please don't 
try to sell me as a fool that all this comes without a cost. This is 
just not true.

>
>> Mind you, we, the developers don't always have all the toolchains available on our developing platforms.
>> What would make this whole branching very cool is if we could somehow tie it with testing such that we are able to tell the testrunners to use our feature branch to run the tests (of course this must be automated in a way).
>
> I agree something like that could be nice, but I think the gitflow
> model is already very cool without it. :-)
>
>> I think in this scenario, a modularized boost will come in very handy ... Think of the VHDL model,
>
> Do you mean this? http://en.wikipedia.org/wiki/VHDL
>
>> you have unit tests, but the module under test might be very different, though the unit tests stay the same. This is something i would really like to see.
>
> Could you clarify? I don't see why we would want to test a different
> module with the same unit tests.

Yes, I mean the hardware description language. Let me explain:
In VHDL you usually start prototyping your new design by writing some 
behavioral description at a very high level, almost like you do with a 
"normal" programming language. After you are done, you start to write 
your unit tests for that. You do that by writing a very generic unit 
test and refer to your new design as "device under test". After you 
successfully passed all the tests, you start by getting down one level 
in the abstraction, lets say RTL level (Register transfer level). After 
that you plug that new device into your unit tests to ensure correct 
behavior.
Now, imagine that different branches are seen as different devices, so 
to say. Instead of letting the test runners run the unit tests defined 
in the main branch, you let'em run the unit tests in your new feature 
branch, completely transparent for them. This means that you don't need 
to disrupt regular service by committing a half done feature to the main 
branch, but get the full advantage of the different test runners.

> -Julian
>
>
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost