Re: [Gnu-arch-users] Re-linking to revlib implemented

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > Just yesterday I said "One of the best ways to get people to do what you
    > want is to make it really easy".  I'm going to think about what would
    > make microbranching so easy that everyone would do it.  It might be
    > easier to work backwards-- some form of commit that takes a branch as
    > the argument, then commits the changes to both the current tree and the
    > specified branches.

That'd be schwell.  It's essentially the "prism merge" technique
that's been discussed on the list.

The tricky part for automating it is the possibility of conflicts.
Suppose that I'm working on a tree which has lots of stuff from
various branches.   I want to extract the current set of changes and
commit them both to my trees version and to some separate branch where
they are part of an isolated change.    What if they conflict with
what's already there in that separate branch?

What I do when I prism merge by hand is commit in multiple steps,
keeping multiple project trees around:

        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.

Perhaps the thing to do is to do it _lazilly_.   That is:


        1) (in multi-purpose tree) commit with log keyword branch=foo

then later:

        2) cd ../other-tree
        3) make a list of all patches from multi-purpose that have
           the branch=foo keyword
        4) replay --list those, fixing conflicts along the way
        5) commit

At least then all the conflict-resolving activity is batched up.

-t