[Gnu-arch-users] IDE not prism-commit? (was Re: Re-linking to revlib implemented)

[Tom Lord]

    > From: Aaron Bentley <address@hidden>
    [regarding the "prism-merge technique"]
    > >         1) what-changed -c ,changes in my multi-purpose tree
    > >         2) mv ,changes ../other-tree  ; cd ../other-tree
    > >         3) redo ,changes
    > >         4) fix any conflicts
    > >         5) commit
    > >         6) cd ../multi-purpose-tree ; commit
    > > It's step 4 that can't be automated away although in the common case
    > > it's a noop.

    > How about 
    > 1) what-changed -c ,changes in my multi-purpose tree
    > 2) mv ,changes ../other-tree  ; cd ../other-tree
    > 3) redo ,changes
    > 4) cp ../multi-purpose-tree/`tla make-log -d ../multi-purpose-tree` `tla
    > make-log`
    > 5) if [ -n "`find -name '*.rej'`" ]; then echo "Not committing to
    > branch"; else commit
    > 6) cd ../multi-purpose-tree ; commit

Well, that's the same thing.    BTW, the right way to notice conflicts
is on the exit status of `redo', not by looking of `.rej' files.

Oh, and, I left something out.  Step (6) should probably include a
sync-tree with the feature branch.

Most of the harder questions that have kept me from implementing this
in the past are "just" user interface issues.   A few are semantic
issues.

For example: 

* When using this technique I'm basically hacking on N-distinct
  similar trees.  How much of that is automated?  Is there a separate
  command to create the trees?  Is there a fixed convention for how
  they are named and where they are located or are their "pointers" in
  each tree to the others?

* Should the `prism-commit' command take steps to ensure that each tree
  is in the state it assumes its in before operating on it or trust
  the user and permit users to modify them freely?   (e.g., what if
  I have uncommitted local changes in a branch tree -- or have used
  set-tree-version to change the branch of a branch tree)

* If the patch application to the feature branch fails should the
  commit of the multi-purpose tree proceed or be aborted?  

* If the patch application to the feature branch fails should that
  feature branch tree be left in some special state to prevent
  subsequent patch applications and commits until the user declares
  the conflicts resolved?  

* If I make some changes on the multi-purpose tree, try to
  prism-commit command, and get conflicts on the branch -- assuming
  that my multi-purpose tree isn't committed in that case -- do we
  need a special undo command to restore both the multi-purpose tree
  and the branch tree?

* When I wind up editting two similar looking trees (multi-purpose and
  branch) I am likely to wind up with multiple editor buffers open on
  same-named files in the two trees.  In my experience, this is
  confusing and error prone -- I'd really like some very grossly
  apparent visual cue like black backgrounds in multi-purpose tree
  windows and distinct background colors for each branch tree.  I'd
  like to be able to navigate like "in another window, take me to this
  same line but in the branch tree".   What kind of support should
  arch provide to make this easy?

* The graphs I actually want may be even more complicated than what
  we've talked about.   So far we have:

                           <-- various 
        multi-purpose-tree <-- feature
                           <-- branches

  where the arrows indicate "merge-to <-- merge-from".   (And, yes, 
  I've drawn that right.   Even though I do the work on the
  multi-purpose tree, the patch logs make it look like I did the work
  on the feature branches and merged into the multi-purpose tree.)

  But what I will more typically want is:

                           <-- some      
                           <-- feature
                           <-- branches
        multi-purpose-tree ..........
                           <-- other     <
                           <-- feature   <----> integration branch
                           <-- branches  <

  where the double-headed arrow "A <--> B" means star-merging back
  and forth between A and B.  (And I can easilly wind up
  wanting more than one integration branch.)

  Do we want to further automate integration branches?


The point of spinning out the more complex scenarion (like integration
branches), mentioning the issues about keeping track of tree states
(like "this branch tree has unresolved conflicts") and mentioning
issues with ancillary software (like editor window background colors)
is to advance the hypothesis that perhaps the core of what's needed
here is not a perfect "prism-merge" command but, rather, a really good
branch-oriented IDE that helps me navigate and manage multiple similar
trees simultaneously, visualize merge histories, persistently keep
track of work agendas (like "trees B, C, and D have unresolved
conflicts"), and use a more scriptable and
passive-recognition-oriented interface for issuing tla commands.   

If I had an IDE with those features, I'm not so sure a separate
prism-commit command would be needed at all.

If I had a separate prism-commit command but no such IDE, I'm not sure
I've gained very much.

Another way to look at this is in terms of labor vs. tools.  Absent an
IDE or perfect prism-commit command, I can still do these patch flows.
I'm have to do them "by hand" and I'm much more likely split the work
up across multiple people.  To a certain extent, what we're talking
about is very similar (in some cases exactly the same) as patch flow
in the arch project --- except that in the arch project a given patch
will pass through two or three hands instead of just one.

My perception is that the main reason it takes two or three hands for
this kind of patch flow is just one of organizational complexity.  The
actual steps of prism-merging are easy --it's all the tree management
that's hard.  I could organize my own "internal" work that way (and
did for a month or two as an experiment) -- it pays off in some big
ways to do that.  But it's also very tedious to keep track of so many
trees and tree states.  A nice IDE -- a kind of "project tree
secretary-bot" -- could make that pay-off/complexity trade-off much
nicer.  A prism-commit command wouldn't address most of the
tree-management complexity issues.

(Another thing I learned from my experiment is that strict
prism-merging is great but insufficient.  Every now and again it
becomes necessary to improvise a little bit and use a different
technique.  This is another way in which just a `prism-commit' command
wouldn't help: it's really the tree-management stuff that's missing.)

-t