Consistency check failure when moving from BK4.1 to BK7.3.1CE


#1

Hi,

Some project in my company was still using BK4.1 and while trying to move to BK7.3.1CE, they are encountering the following issue:

bk clone <source_repository>
Clone file:<source_repository>
-> file:
[check] 100% |==============================|
check: serial 80162 doesn’t match ‘PTAG(s, d) == p’ at slib.c:3285
check: serial 80162 doesn’t match ‘PTAG(s, d) == p’ at slib.c:3285
Consistency check failed, repository left locked.
clone 100% |==============================| FAILED

Any idea on helping them overcome this?

Thanks and regards,
Cyril.


#2

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


#3

That is an interesting failure.

In the code it looks like this:

		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.


Issues with things like bk clone, after upgrade