Chris,
Yes please proceed. I will try to get an answer for your KernelTests
question when I get home in a few hours.
I think there is a good chance that what you are proposing will work.
Thinking back to the update that I tried, I realize that I left the
original update map in place such that the updater first loaded
Chronology-Core-dtl.1 (with no ancestry), followed by loading the
"changes" in Chronology-Core-dtl.2 (with Kernel ancestry attached).
Possibly that confused the updater, leading to the lock up that I
observed.
My only caution would be to keep a copy of the original MCZs to restore in
case this does not work when you test the update stream.
Dave
> Since I already have an update I wish to add to Chronology, I need to
> get its ancestry minimally in order first.
>
> Bert had the suggestion that we could carve out the Chronology MC
> definitions from past Kernel packages and make an all-new ancestry for
> Chronology. I really like this idea, but it will take some time to do
> it.
>
> In the meantime, I wish to ensure the minimum ancestral documentation
> is captured into the new Chronology packages. If / when a
> full-history carve out of Kernel into Chronology is complete, those
> files can replace the ones we develop in the meantime.
>
> Dave, I made new nodes, Chronology-Core-dtl.1 and
> Chronology-Tests-dtl.1 are disconnected (we should probably move them
> to Treated).
>
> Also, what happened with KernelTests? There was a duplicate ancestor
> (dtl.306 and dtl.307) but 306 is not in the repository. So, I hope
> you don't mind, I felt the need to clean up this corruption so that
> the SCM tools won't blow up when they go looking for that missing
> ancestor.
>
Locked
