Change-Least Evolved Branch

>>>>> "Brad" == Brad Appleton-GBDA001 <Brad_Appleton-GBDA001 at email.mot.com>
>>>>> writes: 
> John Mitchell writes:
[...]
>> I.e., the mainline is truly just a main line from which everything
>> branches.

> Thats one possibility, but the way Chris and Laura describe it, mainline
> is consistently used for the latest and greatest (LAG) development; and
> you don't branch off of mainline until as late as possible. So I don't
> branch off for release 2.0 at the very beginning, I would wait until work
> for 2.0 actually needs to take place concurrently with previous and/or
> subsequent releases.

Okay, and so my argument is that I *did* branch late -- at the very point
where concurrent development was necessary (i.e., the point at which
changes would be made to the codeline for the v2.0 release that would be
substantive differences from the living v1.x codeline).  My model branched
the v1.1.x line as late as possible and doesn't preclude continued releases
on the v1.0.x branch wherein you are mutating the v1.0.x codeline into the
v1.1.x codeline (which against one of the other rules :-) which also means
that my v1.1.x branch got a bunch of v2.0 development features "for free"
since they happened before I branched v1.1.x.

Now, given all of that, depending on the nature of the v2.0 development
work, I may well have not branched a v2.0 dev branch until after v1.1.x was
cut and so my diagram would look the same as yours except for the mutating
codeline rather than the separate branch issue (which I do think are
critical).


> However, none of that really changes my question IMHO.

Ah, sigh. :-( :-)


>> Laura's & Chris's rule of thumb is, IMVHO, addressing the issue where
>> you have a change that you know has to eventually end up in multiple
>> codelines.  I.e., it addresses the question of "where *should* you
>> *introduce* such a change so that it is the easiest to deal with."

> Yes - that is the same thing that I was talking about before (at least I
> intended it to be). In the case of a fix to 1.0, you would know that the
> fix must eventually make its way into both 1.1 and to any subsequent
> release of 1.1 (including 2.0).

It depends on the fix to the v1.0.x.  In my diagram, I showed the case
which you're talking about where all of the v1.0.x changes are sucked back
into the mainline but I also showed the v1.1.x branch dead-ending on its
own without a final merge back into the codeline since both cases are
common.


>> So, in the above situation, I (johnm) decide to make a bunch of drastic
>> changes to the 2.0 dev branch.

> And here is the *crux* of the problem. Its not the stuff you talk about
> later, its why you chose to modify 2.0 dev if you thought one or more
> other branches were equally likely candidates. If you didn't think that
> far ahead, okay - but then the "change least evolved" is no longer
> applicable because you've already started the changes on that branch, and
> its referring to the choice of what the branch should be. So I can
> certainly understand the rest of the scenario you described, but I don't
> believe it falls under the case we're talking about (for reasons
> previously stated).

Okay, I can buy that but I still think it does for the very fact that often
developers find themselves primarily working on a give codeline and so it
can be difficult to "switch gears".


>> Indeed, that's part of why I think your codeline model needed changing.

> The model you drew was fine but it didn't really change anything IMHO
> with regard to the question I was asking.

Well, I guess we may just have some fundamentally different perspectives on
this.  Oh well. :-)

I think that we agree that regardless of our philosophies, the issue is
still "where *should* the change be made initially such that the least pain
is involved in integrating everywhere else that it needs to be."

A point of my example is that at the point in time when I wanted to make
the changes in my v2.0 dev branch, again assuming that I'm smart enough, a
change to e.g., a utility routine that is applicable to e.g., all of the
other codelines existing at that time, then the "least evolved" rule of
thumb says that I have to *think* about which codeline for which that
change is applicable has mutated that file least since its (the codeline)
inception.  That will most likely give me (a) the easiest initial change
and (b) the easiest set of integrations into the other codelines (i.e., the
minimum number of conflicting changes).  Again, I see this as a rule of
thumb as we can definitely think of nasty cases that are nasty no matter
what.


[...]
> Regardless, even if you use a separate codeline for each and every
> release (but still branch back to main eventually), I don't see how it
> fundamentally changes the original question.

>> Hell, think about the case where the v1.1 release branch is cascaded off
>> the v1.0 branch or has to proceed in parallel to the v1.0.x branch

> Frankly - I don't see how that changes anything. For any given
> fix/feature, someone (often the project lead, but not always) has to
> decide which of the currently "in-progress" set of releases (e.g. 1.0.1,
> 1.1.0, 1.1.1, 2.0, etc.) should have the fix/feature. This is rarely
> decided by looking at the branch topology (nor should it usually be
> decided that way). Its usually decided by looking at business reasons for
> which functionality should go in which releases, and is often accompanied
> by advice on whats technically feasible. Frequently, the deciding factor
> is schedule.

Ah, then we do have a fundamental difference here.  I think it clearly
makes a huge difference.  The cascade model (where you end up with branches
off of branches off of branches...) makes the very problem that we're
discussing harder to deal with.  The deeply forked branches mean that the
closest common ancestor for some files will be horribly distant and thus
the "least evolved" rule is most likely a crap shoot and thus you just have
to take the pain of multiple, nasty integrations.

In my view, I don't care why certain branches need the fix or not.  All I
care about and, IMVHO, all the rule of thumb is saying that once you've
decided on which branches are to be affected by the change that you pick
the one that is going to give you the least amount of pain -- the one that
has been least mutated since the closest common ancestor.

It seems that you go to some lengths to keep the proliferation of
"codelines" (using your definition even) to a relative minimum by doing
things like mutating branches (i.e., v1.0.x mutates into v1.1.x).  I take
the admonition "a branch for every purpose, a purpose for every branch" as
a much stronger rule than the "least evolved" rule of thumb.


> So once you know the earliest such release (which in this case would be
> the lowest numbered one), then you typically will want/need it to migrate
> to all successors of that release. At that point, there should be one and
> only one publicly available codeline (not any old branch, but a
> "codeline", using my earlier definition) for which work for that release
> is taking place (again, this rules out consideration of singly activity
> branches off the codeline, or other peoples private/personal codelines
> branched off the codeline). This is the codeline where you make the
> change, and it gets propagated, in release-number order, to all
> subsequent codelines. I don't see why the question of "what is least
> evolved" should ever be entering the picture when deciding which codeline
> to originate the changes in.

And this distinction, and your given model, is why you're confused.  In
your model, it seems less relevent because you've traded off other pains
for a simple, but not necessarily painless, answer to this rule of
thumb. I.e., to your view, this rule is silly since it has a more or less
trivial answer.

Of course, I could just be suffering the effects of too much super-crack or
something. :-)

Take care,
	John