This falls way outside what could be considered something that would be supported for free.
Even with commercial support you only get support 18 months back.
BK 4.1 is around 10 years old:
$ bk changes -rbk-4.1
ChangeSet@1.1875.1.3, 2007-10-12 15:19:13-07:00, rick@work.bitmover.com
This is a classic example of why you might want commercial support, this is not something
that any organization can be expected to do for free.
For anyone following around, this is coming from one of our larger customers who have
decided to go with the free version of BK (they no longer have any commercial seats).
Which is fine. Expecting commercial support for free is not so fine. I’ve looked at
the problem and it’s non-trivial to fix (and most likely would not be a problem if they
had upgraded as we did releases).
if (TAG(s, d)) {
tagassert(FLAGS(s, d) & D_META);
if (p = PARENT(s, d)) {
if (TAG(s, p)) {
// must be tag merge
tagassert(PTAG(s, d) == p);
tagassert(MTAG(s, d));
tagassert(SYMGRAPH(s, p));
tagassert(!SYMBOLS(s, d));
} else {
Serial 80162 is ‘d’ and it is a TAG node in the graph. This is from the tag graph which is a DAG separate from the commits that encodes the tags. Like commits, each tag delta has parents and merge parents. So PTAG/MTAG are the parents in the tag graph and, for a tag node, PARENT is pointing at the commit that is being tagged. Here PARENT is pointing at another TAG node which can only happen for a tag merge and so PTAG should be pointing at the same parent. In your tree it isn’t, so we assert.
Try running bk _heapdump ChangeSet and look for ‘serial 80162’ and follow the links and see what is going on. Perhaps paste some excerpts here.
Also, I have been doing to consulting on BitKeeper independent from the Bitmover company and I could be hired for a short time to investigate your problem directly if you like.