Change-Least Evolved Branch

[Brad_Appleton-GBDA001 at email.mot.comBrad_Appleton-GBDA001]

In Laura and Chris' "High-Level SCM Best Practices" paper (see the
whitepapers at: http://www.perforce.com/perforce/technical.html),
they have a practice called:

  Make original changes in the branch that has evolved least
  since branching.

I have two problems with this. First, lets use an example to help make
the discussion "concrete." Suppose I am using a "mainline" that is
currently beind used for features in the upcoming 2.0 release. Suppose
further that some short time back (say one month) a branched off a 1.x
codeline for all subsequent v1.0 releasing and maintenance (so it will
have work for v1.0, 1.1, 1.2, etc.):

                                   (more 1.0)    (1.1 and beyond)
                         1.X-line +-----------*-------------------->
                                 /
                                /
  mainline --------------------*----------------------------------->
             (1.0 development)     (2.0 development, and beyond)


For starters, their seems to be an implication that the 1.X is "less
evolved" than mainline since the time of the branching. It would seem
by "least-evolved" they mean that there are more changes in the
mainline (since branching) than in the 1.X-line. This need not be true
at all however. I may have only a few features that required a lot of
though completed on mainline since the branchpoint, while I've had a
whole flurry of bugfixes in the 1.X-line. Even if you go by the "size"
of the difference in configurations (instead of the number of completed
tasks), there more be more changes lines and files in the 1.X line then
the mainline (the new features may have required a lot of thought and
design, but not nearly as much code).

So the definition of "least evolved" doesn't seem to work here. I need
another one. Maybe its simply the "youngest" codeline (overall, in spite
of where the branchpoint is).

Also, in the above scenario, the "change least evolved branch" advice
is saying that if I need to make a change that eventually goes (via
propagation/merging) into both mainline and 1.X, that I should change
1.X and propagate to mainline instead of the other way around
(otherwise I might pull unwanted 2.0 changes into 1.X).

I simply don't understand why this scenario isn't a complete "no brainer"
and why its not obvious that 1.X fixes go in the 1.X codeline and the
direction of any propagations should always be FROM 1.X TO mainline
(for all but the rarest of exceptions)???

I would think that any and every "change" has an intended "target
release" (or something very close to it) associated with it and that
this would leave very little ambiguity as to which codeline the change
needs to be originated in. Of course, that info has to be communicated
to the person making the change, but if it isn't, I think the problem
lies there, and should be resolved by asking for further clarification,
rather than contemplating which codeline is the "least evolved."

Is there something more profound and insightful in this advice that I've
missed, or is it simply a clue for the clueless? Why wouldn't the
appropriate codeline and merge direction not be pretty darn clear in
the policy for the 1.X codeline??

Thanks in advance!
- -- 
Brad Appleton <bradapp at enteract.com> | http://www.enteract.com/~bradapp/
 "And miles to go before I sleep."   |  3700+ WWW links on CS & Sw-Eng