help getting a clue about tracking changes in an integrated library

[Stephen J. Turnbull]

Chris Hecker writes:

 > This is exactly the "poor man's nested branch" model. Since you've
 > > invented it for yourself, it's the obvious way for you to go.
 > 
 > No, I think this is different.  I'm proposing this:
 > 
 > repo1 - trunk -+- src
 >                 |
 >                 +- lib
 > 
 > repo2 -+- lib-mine
 >         |
 >         +- lib-mod
 >         |
 >         +- lib-orig

 > lib-mine and trunk/lib are not in the same directory or symlinked
 > or anything, which if I understand the hacky nesting is what you're
 > suggesting (hence the bzrignore lib).  I just copy between lib and
 > lib-mine with, like, cp.

I don't think I could make that work.  I would be forever making
changes in repo1/trunk/lib that wouldn't get synced to repo2/lib-mine,
and these would probably regress on updates to lib via lib-orig or
lib-mod.

 > This sucks, because lib and lib-mine need to be synced, but at
 > least repo1 is atomic and can be rolled back, which does not work
 > with the PMNB model, right?

Not directly in bzr, right.  How about

$ cat > rbzr <<EOT
#! /bin/sh
bzr $@
case $1 in
tag|rollback) for d in lib1 lib2; do cd $d; bzr $@; done ;;
esac
exit 0
EOT
$ rbzr commit -m "And now for something completely different..."
$ rbzr tag idle
$ rbzr rollback eric

then?