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

[Aaron Bentley]

On Thu, 2004-01-15 at 14:20, Tom Lord wrote:
> 
> 
>     > From: Aaron Bentley <address@hidden>
>     > 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.

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

That's all scriptable, though you'll sometimes need fix the branch and
commit.  And to prevent mistakes, we can abort before 1) if the branch
contains rej files.

(caveat: we need a way to get the merge log name without creating a
file.)

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

Actually, I see that as a drawback.  You'll be best-prepared to handle a
conflict in patch-7 immediately after you've written patch-7, not after
you've written patch-13.

Aaron

-- 
Aaron Bentley
Director of Technology
PanoMetrics, Inc.