help getting a clue about tracking changes in an integrated library

[Chris Hecker]

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

I guess I value the robustness in the trunk more.  I need to be able to 
come back a year later and sync it to some arbitrary version on another 
machine and have it "just work" without remembering how to set it up. 
It's just too scary to have a core component "not be there".  I actually 
worry about this with real nested trees/externals as well, but the 
design page says it will be easy to create a mirror for the nested 
projects, so I'm assuming that will at least minimize the problem, but I 
could still see things rotting and being unable to sync the project 
correctly to an arbitrary point in time.

marius:
> You may also be able to use one of the following to help you manage
> these branches:
> https://launchpad.net/bzr-externals
> https://launchpad.net/bzr-scmproj
> I've used both in anger and they help a lot.

Interesting.  Are there docs online, or do I need to install them to get 
help?

Chris




On 2010/09/23 00:47, Stephen J. Turnbull wrote:
> 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?
>