Re: [Pika-dev] pika-0.1pre4 tarball broken

[Tom Lord]

[Rob, you might want to note this and think about making a tweak to
--skip-present.]

So, first thing: the subject line is a little misleading.

There's nothing actually _broken_ about the tar bundle in the sense
that everything, arch included, seems to be working properly.

But it is "broken" in the sense that the way one of the merges got
done makes subsequent `replay' calls not work as you'd guess from the
way I usually manage mainlines.

    Andy: 

    > I also ran into this with 'tla replay', which tried to apply pacth-172
    > a second time. I ended up deleting the scm dir re-running and
    > build-config.

I'll make sure that the next release isn't "surprising" in that way.
Sorry for the confusion.  As Matthew pointed out, replay
--skip-present would have worked (but normally that's not necessary if
you're just tracking one of my mainlines).

I did some archaeology to see what happened.  The following is arch
rather than pika specific but does explain what's going on:

Roughly speaking, when you have multiple developers working on
branches that get merged back and forth, there ought to be a little
bit of agreement about how those merges will be done.  For example, we
might agree to keep roughly to a star-topology and and so both use
mostly star-merge.  Or we might agree to mutual cherry-picking, and
use "replay --skip-present" a lot.

In this case, I have a guess about what happened (but a pretty good
guess, I think):

The surprising absense of the patch-172 log occured because Matthew
merged from me using a cherry-picking technique (replay
--skip-present) whereas I merged from him using a star technique
(star-merge).

In patch-172, I merged a bunch of changes from Matthew, catching up to
address@hidden/scm--devo--0.1--patch-11.  In my patch-173, I
fixed a compiler warning that some of the new code had triggered.

Matthew created address@hidden/scm--devo--0.1--patch-12 by
merging up through my patch-173.  Here's the catch: I think he did
that either "by hand" (skipping my patch-172) or (more likely) using
replay --skip-present.

Replay --skip-present looked at my patch-172, saw that it just merged
in a bunch of Matthew's patches that he already had, and so skipped
patch-172.   It saw that patch-173 was new and applied that.   So if
you look at Matthew's patch-12, you can see that my patch-172 doesn't
show up in his logs, even though the changes are all there already
(since they originated on his branch in the first place).

Later on, not realizing that Matthew had been cherry-picking, I
star-merged against his tree (to pick up some later changes).
star-merge looked for our common ancestor revision, compared that to
his latest, noted among other things that his latest didn't have a log
file for patch-172, and so deleted the log for patch-172 from my tree
as part of the merge.

Note that if I had also used replay --skip-present, my patch-172 log
wouldn't have been dropped.

And note that if Matthew had used star-merge instead of replay
--skip-present, my patch-172 log wouldn't have been dropped and would
also be present in his development line.


    > Matthew Dempsky <address@hidden> writes:

    >> If you download the pika-0.1pre4 tarball, it seems that
    >> patch-172 has already been applied, but running "tla missing"
    >> reports it as a patch that still needs to be applied ("tla
    >> missing --skip-present" works though).  patch-172 is also
    >> missing in "tla changelog".

Matthew:  do you mind if we switch to using star-merge between our two
development lines?   When I get the numerics scaffolding done I can
send mail explaining what you should do to sync up and then we can
star-merge thereafter.

I was tempted to suggest we both switch to `replay --skip-present'
instead but it really isn't quite appropriate for this situation --
it's better suited for situations where you really _have_ to
cherry-pick back and forth between multiple lines in a non-star
topology and are therefore willing to adopt a discipline of always
committing merges "purely" (without any other changes).   Since I want
to make it easy for other people to also make branches and contribute
to the mainline, I don't want to add the burden for all contributors
to have to maintain that "pure merge" discipline.


[Rob: should --skip-present add the logs for patches it skips?
 An advantage is that it would have avoided this problem;  a
 disadvantage is that someone blows pure-merge discipline that
 it's harder to figure that out by looking at the logs to see what
 --skip-present skipped.]

-t