Hi Keshav,
that's the diagram I have the most stomachache with:
(snip)
>
> How it would work given current practices
> -----------------------------------------
>
(snip)
>
> 5) Another release is made, incorporating the developer's changes (X, M,
> and Y), but first backing out the changes made in A, with commit D.
> Pulling in the developer's changes also pulls in the two old copies of A
> and B and one copy of C from the previous two dev releases. This release
> now incorporates X, M, Y, D, E, old A, old B, old C, older A, and older
> B on top of what was in the previous release.
>
> A == B == X == M == Y
> // // \\
> /=== A == B == C \\
> // \\
> o == A == B == C == D ===== E
> ^ ^ ^
> 1 2 3
>
(snip)
>
> Please tell me if anything else about what I said, in my previous
> post(s) or this one, is insufficiently clear - I hope the diagrams are
> of some help! And of course I welcome comments about the other points I
> have made as well.
>
> -Keshav
>
Well,
I'm not perfect, and I know it, and so I appreciate your patience with
me, trying make your point(s) clear. Alas, I still have my problems,
and I hope to be able on my side to explain those to you. So let's
define our entities. There are (a finite set of) "releases" (say
"rel0", "rel1", "relA", ...) for each of which there is a (regression)
testsuite (which has to be passed "OK" as a basic assumption
throughout). There are (a finite set of) "developer changes" (patch
sets from trac tickets), called "A", "B", "X", and so on. For the
latter, there are the notions of "(doc)test", "depends on" and
"history". Let's dwell on the "depends on" notion a bit further,
giving a formal definition.
0.)
Each developer change A "depends on" some release, say e.g. relA, and
A possibly depends on some other developer changes "with respect to
(w.r.t)" relA. Those other developer changes must "depend on" the same
release relA, and we make it an axiom that every "dependency
graph" (consisting of such an A, relA, and the set of developer
changes that A "depends on" w.r.t relA, and so on, i.e. the "closure"
of those that these depend on w.r.t relA) is a tree, i.e. contains no
circular dependencies.
A developer change A may "depend on" several releases rel0, rel1, ...
and if this is the case, we may have different respective sets of
those developer changes, that A "depends on" w.r.t. these releases
relA, relB, ...
We assume throughout that any developer change both can be applied to
a release it "depends on" and is only applied to such a release, if
all of the other developer changes it "depends on w.r.t. that
release", had been applied previously (our axiom makes this feasible/
reasonable).
1.)
A developer change B does depend not only on some release rel0, but
also "depends" on developer changes A', A'', A''', ... (possibly only
one A) "w.r.t. rel0", if B's patch does apply (no merge conflict, or
at most a trivial merge conflict, i.e. only trivial fuzziness like
shifted line numbers, or whitespace changes) to
"rel0==A'==A''==A'''==..." (rel0 and all those developer changes
applied), *but* shows a non-trivial merge conflict when one tries to
apply it directly to "rel0", i.e. without having these other developer
changes applied first.
2.)
Some B also "depends on" some A w.r.t. some release rel0 (even if 1.)
is not the case), if any doctest of B is "OK" in the presence of A
(both applied to rel0), but is "NOK" in the absence of A (B applied to
rel0, but not A).
3.)
Some B also "depends on" some A w.r.t some release rel0 (even if 1.)
or 2.) or both are not the case), if the testsuite of rel0 is "NOK" in
the presence of B and when A is not present, but the testsuite passes
when both A and B are applied (all w.r.t a certain release rel0). (In
other words: without A applied first to rel0, B would introduce a
regression in the testsuite of rel0.)
4.)
Some B does *not* "depend on" some A w.r.t. a fixed release rel0, if
none of the above conditions 1.), 2.), 3.) holds.
A "developer change" has one or more "(doc)tests" if it's a bugfix, or
feature enhancement (possibly no doctest if it's only a spelling
correction in a comment ...). If we apply a series of developer
changes A, B, C, ... to some release rel0, and after that the
testsuite of rel0 still passes OK, as well as all of the new
(doc)tests from A, B, C, ... then the result may become a new release
rel1, the testsuite of which is the union of the old testsuite and
those (doc)tests.
Now take up the given example, and say developer "Linus" has released
some ("official") release "rel0", and later some ("development")
release "rel1" which is just "rel0==A==B", i.e. rel0 applied two
developer change sets A and B to rel0, none of which depends on the
other. (To say it explicitly: A does not depend on B, and B does not
depend on A, but both depend on rel0, in the sense defined above. The
testsuite of rel1 is the union of the testuite of rel0 and the
doctests of A and the doctests of B, passing OK.)
Continuing the example, say developer "Greg" had started from the
"rel1" of Linus, and developed a developer change X on top of it, so
that "rel1==X" (which alternatively can be written as rel0==A==B==X)
would be a valid release (X "depends on" rel1, and when X is applied
to rel1, then both the testsuite of rel1 as well as the new doctest of
X pass "OK").
Now Linus releases ("developer" release) rel2, which is just rel1==C
(and is also rel0==A==B==C), where none of A, B, C depend on one
another except for possibly that C may (or may not) depend on B
(w.r.t. both rel0, and rel0==A, to make that explicit), and later
(again "developer" release) rel3, which is rel0==B==C (there is no A,
as if it would have never been applied).
Greg tries to apply X to that new rel2 (rel0==A==B==C), and hooray,
there's some interference with C. For the sake of exposition let's say
he needs to create and apply M to rel2 before he can even apply
(merge) X to rel2, so that w.r.t. rel2 X now "depends on" M. And let's
say if Greg only applies M and then X to rel2 (which now works
technically), then still the doctest of C breaks, causing a
regression, so he needs Y to clean that up also. So w.r.t. rel2, X
also depends on Y. Let's also assume that M and Y do not depend on
each another w.r.t. rel2. So Greg ends up with a valid release
rel2==M==Y==X.
Finally, Linus wants to incorporate the developer change X into his
the next one of his release series, more precisely "on top" of rel3,
i.e. rel0==B==C. Note that by the above assumptions, we can apply A to
rel3. Now there are exactly two possible cases:
- Either none of M, Y, X depend on A w.r.t. rel3 ---> then Linus may
create rel4 as rel3==M==Y==X (thus rel4 may be alternatively written
as rel0==B==C==M==Y==X).
- Or, at least one of M, Y, X depends on A w.r.t. rel3 ---> then Linus
has to take A "back in" if he wants to get further.
Now, in the first one of these two cases (say Linus released the
mentioned rel4 as his next "official" release), I cannot see how any
reasonable notion of "developer history" of this rel4 would
necessitate any mention of the developer change A --- rather to the
contrary, it shouldn't mention A!
To explain the latter, let's modify the example slightly, and change
the perspective.
Say Greg had developed his developer change X not on top of rel1 of
Linus, but instead on top of a public (!) release relG of his own,
where relG was rel1==W (rel1 as above, and applied some developer
change W to it). Now assume that *in every possible sense* X does not
"depend on" W, but that rel1==X never existed in reality, only
relG==X, i.e. rel1==W==X (and the patchset of X was "drawn" form
there). Then Linus might still be interested in pulling in X into his
releases, but be totally *not* interested in W, or anything about W,
let alone talking about W in the "developer history" of his releases.
If Greg now would be forced, in order to be able to push an X with a
"W-free developer history" to Linus (or Linus to be able to pull such
an X from Greg), to artificially go back from relG to rel1 for that,
and to have to manually (!) create X a second time, now based on rel1,
then this would make distributed development an errorprone PITA. But
this is neither my overall impression, nor my personal experience.
Keshav, maybe I have misunderstood what you meant by "Pulling in the
developer's changes", since I am still totally at a loss, how your
notion of a "developer history" could result in duplicate or even
triplicate entries for one and the same developer change A. Either A
was (ultimately) applied, or not ---and in the latter case a
"developer history" entry for A may and should be omitted (nothing
depends on A, so ultimately A did not need to be applied, and wasn't).
My attempt of some more formalized definition of "depend on" might
fall short of reality, but I hope it helps us further to understand
each other, as your explicit example did!
Cheers,
Georg
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
