[Gnu-arch-users] Re: advanced usage advice: the prism technique

[Pau Aliagas]

On Fri, 26 Sep 2003, Andrea Arcangeli wrote:

> On Fri, Sep 26, 2003 at 01:44:03AM +0200, Pau Aliagas wrote:
> > 
> > I hope this helps you. it's the prism technique :)
> > It's the perfect way to develop in parallel several features and itegrate 
> > them in a common trunk.

        key:
           a <-> b      a and b star-merge back and forth
           a <~>> b     a "prism merges" into b

> the 'pure' version is my -aa tree if I understand correctly.

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

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

In your case, I envision something similar to this:

-you have a working tree where you hack or import patches from other 
 wildly.

-once the  working tree is in a state when and are satisfied with it, you 
 export the complet patchset to one of the pure versions, to keep development 
 splitted in the correct branches, that is un pure versions. That you you 
 qualify what you've been doing and keep it in the expected place.

-------8<-------8<-------8<-------8<-------8<-------8<-------8<-------
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
-------8<-------8<-------8<-------8<-------8<-------8<-------8<-------

-so your pure versions would be:
 linux--aa-vm--2.4
 linux--aa-newgen-schduler--2.4
 linux--aa-new-driver-model--2.4
 linux--aa-new-drivers-model--2.4
as many as you needed to keep development splitted in logical parts.
This way you'd have them ready to merge into your linux--aa--2.4  and from 
here to linux--linus-2.4 (or linux--marcelo--2.4 or...)

> I probably don't need arch to make the simple patches. what I was
> considering to use arch for, was to genreate the "pure" tree only infact ;).

You'd probaby import the patches into a working dir, move it to the 
adequate branch using the prism technique, and then star-merge back and 
forth to the right (aa, linus, marcelo). So you'd keep all your hard work 
sorted, but transparent to the rest. Instead of seeing 20 patches, they'd 
see as many as you'd choose to, depending on how you moved them from 
working dir to pure versions.

> except I've one more need. If a patch doesn't get merged into mainline
> for a long time (and I'm not the one calling star-merge into the
> mainline tree, infact it will hardly happen that marcelo will ever call
> a star-merge [assuming he would use arch]) I really have to keep it
> clean and when I find a bug in one of the patches, I've to fix it
> "overwriting" the old patchset. That could lead to rejects in the
> following ones.

You'd keep all your patches properly sorted in all your branches (aa and 
pure versions). Your aa tree would always be up to date related to 
marcelo and linus because you'd resync with them using star-merge or 
replay, so the non-merged patches would be always ready to export.

> One way I could achieve the above w/o arch changes could be to branch
> the tree at the previous patch before the buggy one. Then I can do a
> get-patch of the buggy patch piped into 'patch', and apply it by hand
> (or maybe with tla redo not sure exactly, I don't know what redo exactly
> does). Then I can commit it, the commit is basically the 'overwrite'
> operation. Then I would need to reply all other patches from the
> previous branch. Is this correct? Is there a way to reply all patches
> from the other branch, except the one that I applied by hand already
> with the bugfix?

I'd make it easier. Goto to the working dir, correct the bug and
prism-merge it to the proper branch. Then propagate the change to aa.  
Again, it feels natural.

You should never try to correct a patch, replacing it with another
because, hopefully, people would mirror you archive and that means that
they'd only get he new patches. You should just correct it with a new 
patch and be done with it. It's a good policy documenting all the changes.
There are methods to remove a patch (tla replay --reverse) that could be 
useful to remove an unwanted patch, but I'm not sure on how to use it 
properly.

> > 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.
> 
> I can't understand this, what's this revision library, and what does it
> mean perpetually up-to-date? if the scripts above are painfully slow
> without this, then I guess I need this too?

Revision libraries are untarred versions, optimized via hardlinks to
unchanged files of previous revision, of projects up to a patch level. 
They are highly optimized in space use, so ot's like convnient having them 
instead of reapplying a large number of patches.

You usually have a hook (it's a shell script) that adds a library to your 
favorite branch every time you commit.

Pau