Re: [Gnu-arch-users] In search of prism merge

[Tom Lord]

    > From: Ron Parker <address@hidden>

    > I have been going through the list mail looking for the original
    > prism-merging description.  I think Tom wrote it, but I believe it
    > predated the gnu.org mailing list and I don't have the old archive
    > available to me on this machine. Could someone please post a copy or
    > point me to the proper archive.

Enclosed.   

Note that currently I'm not using prism-merge for two reasons:

  1) I'm not concurrently working on N different features
     in a way that prism merge really helps with.

  2) The prism-merge process really needs automation but to implement
     that automation I want some of the planned features first,
     such as project tree management.

-t




Date: Fri, 18 Jul 2003 01:10:51 -0700 (PDT)
From: Tom Lord <address@hidden>
To: address@hidden
Subject: advanced usage advice: the prism technique




I'm partly repeating myself, but now with more experience.


This is proving to be a _really_ nice arrangement of development lines
for a programmer working on several things at once.   I'm sure it also
generalizes beyond individual programmers, as well:



        key:
        
           a <-> b      a and b star-merge back and forth

           a <~>> b     a "prism merges" into b




                          pure versions
                          -------------

               | < ~~~~ >> feature a  <---> |
               |                            |
       working | < ~~~~ >> feature b  <---> | mainline
               | ....                       |
               | < ~~~~ >> global c   <---> |


What does "prism merge" mean, as in "working prism merges into feature
b"?

It means that instead of committing directly to "working", I commit in a
few steps:

1) make some changes to working

2) decide which of the pure versions those changes belong on.
   Call my project-tree for this version $PURE_TREE and its version $PURE.

3) in my project-tree for working, run:

        tla what-changed -o ,changes [--diffs]

4) mv ,changes $PURE_TREE

5) pushd $PURE_TREE

6) tla redo -p ,changes

7) tla commit

8) popd

9) tla sync-tree $PURE

10) tla commit


When the changes accumulated on a particular pure version hit a
milestone:

1) cd $PURE_TREE

2) [if not up-to-date with mainline]

   tla star-merge mainline .
   tla commit


3) cd $MAINLINE_TREE

4) tla star-merge $PURE .
   tla commit


Sometimes, then, I'll want to repeat steps (1) and (2) on other pure
versions, depending on the nature of what's just been merged into
mainline.


The net effect: 

"working" evolves chaotically -- lots of commits which are incremental
progress on this or that.

The pure versions accumulate thematically related changes, in
isolation.

The mainline is only ever modified by clean, isolated, changesets.

_Obviously_ it's possible to get into a situation where interference
between the various pure branches complicates the merges in that
graph.  A partial (and for me, so far, quite effective) way to deal
with that is the pure version I labled "global c" -- it's for changes
that I then want to "broadcast" to some or all of the other pure
versions -- for example, to make sure they can keep smoothly
prism-merging from working.

Part of what makes this so incredibly smooth and effective for me is
that my revision library is perpetually up-to-date.   It's updated on
every commit -- there's one line in my hooks file that ensures that.
Otherwise, the scripts above would be painfully slow.


-t