Re: Merging frustration when tracking external projects

Rick Smith wrote:

> The math in BK that makes converging easy works against you
> when keeping B and C separate in the data flow you outlines.
> The solutions have to do with doing some merge again -- such
> as having D be a throw away version, and bring B and C together
> each time.  Since you control B and C, they might be structured
> to merge automatically.

Yes, I have been working towards a solution like this. Unfortunately it 
means I need to build some "machinery" to sit outside BK to keep track 
of what I want in D, and then build it on demand.

I actually did make an attempt to do this, but failed... I built a 
trigger that would run at post-incoming time and pull other repos into 
the current repo. That will not work, though, because even at 
post-incoming time the repo is still read-locked and can't be updated. 
If I could work around that, I could build a "template" for D that was 
just a clone of A, with a list of "siblings" to merge at clone time.

Then, any clone of "D" would automatically pull in B and C _at that 
moment_, not before. That would solve the problem, and also keep me from 
having to keep throwing away and rebuilding D by hand.

Any thoughts as to a method to make a trigger that can pull (merge) 
other repos into the current one?
_______________________________________________
Bitkeeper-users mailing list
[email protected]
http://bitmover.com/mailman/listinfo/bitkeeper-users
To unsubscribe from this list, go to the above URL, follow instruction at the bottom of the web page.