Oh, and I’m guessing that the file is on the hosts that are actually running bk, so I’ll check a few of those, next.
I am referring help debugging the problem yourself by building bk from source and changing the assertion that is causing the problem. You would need an experienced software developer.
OK. I looked at the problem cset. It looks like this:
serial: 2192 (1.390.5.5)
PARENT: 2191 (1.390.5.4)
PTAG: 2190 (1.390.6.2)
date: 1064501421 (03/09/25 10:50:21)
flags: 1201 (SYMGRAPH,CSET)
USERHOST: peter@smithers.revahertz
PATHNAME: ChangeSet
comments: ChangeLog:
Changelog Entry for 0.2.324
This is a cset that is also on the tag graph. PARENT is the parent of this cset. No MERGE means it is a normal cset and not a merge. PTAG is the parent on the tag graph. Since this has both PARENT and PTAG it means it is part of both graphs and is created with 'bk commit --tag=TAG' which people often do when releasing a new version. The comments kind of match that. However, the ‘flags’ field is missing SYMBOLS so there isn’t actually a tag on this node. So this is a noop on the tag graph and should not have happened. That is why the assertion happened.
I am wondering if the tag was lost at some point or something. This damage probably happened long ago, but wasn’t discovered until the new consistency checks for the tag graph.
Commenting out that assertion and using bk would probably work in a pinch. Or doing surgery on the tree to add back the missing tag. From looking at the other tags it was clearly v0.2.324.
We won’t be building from source. Do you have instructions on “…doing surgery on the tree to add…”? Is there no switch to use that will bypass the check. Also, can you comment on this, i.e. does this behavior alter your opinion of the failure.
We have two repos 1.26 and a 1.27 that was very recently cloned from 1.26. If I clone 1.26, after running the check on the first level repos, it fails with (check: serial 2192 doesn’t match ‘SYMBOLS(s, d)’ at slib.c:3318). If I clone the 1.27 repo it works fine but after completion if I run the bk -r check -a I get the error above. Other can clone 1.26 but fail to commit to the clone, I can’t clone that one. Any reason for the different behavior?
Sorry for the delay. All day field trip with the kids. One of the advantages of being unemployed.
You had a lot of questions here, let me address some of them one by one.
That’s going to make this harder. Is there a reason for that?
No
Usually, it looks something like converting the ChangeSet file to the ascii format, editing the file to add the missing symbol, recomputing the now incorrect checksums and putting the modified file it back in place. It takes time and effort to put together a set of instructions and test them to be sure they work. And the result will fix one repository and any closes of that repository. The fix wouldn’t propagate on pull.
In what way? My summary is the same.
- the problem cset is from 2003
- some old version of commercial version of BitKeeper lost a tag that used to be on that cset
- this problem was later fixed and doesn’t happen in current trees.
- the bk-7.x series introduced new consistency checks that exposed this problem. This release was mid-2016.
- the problem could probably be ignored while you are transitioning to git.
For performance reasons, bk does not do full checks after all operations. If a tree has passed a consistency check recently then a clone of that tree that doesn’t need to change anything can skip this check. But as I understand you an explicit check of both trees fails the same way.
In summary, you could comment out the problem line and move on.
We rebuilt from source and fixed the problems.
Wayne -
Hey this is Larry again. Any chance you might be able to feed us just another wee bit of help? We’re way further along than before, managed to get several repos baselined and imported into git with history, etc. But I’m having trouble with the incremental fast-export.
I baselined, imported, and pushed the “product-reveal-1-26” repo. Complete with history, all good.
Now I pulled from bk our incremental branch “product-reveal-1-2600” - which should have several additional csets - and I want to make that a corresponding branch on git. So I did:
bk fast-export --branch=1-2600 --incremental=../domestic/product-reveal-1-26 > ./archive/pr2600.bak
(export the new csets only since 1-26)
rsync -avz --exclude 'SCCS' product-reveal-1-2600 domestic (copy and eliminate the SCCS files)
cd ../domestic/product-reveal-1-2600 (move to the clean branch)
git init (set up the empty git repo)
cat ../../product-reveal-1-2600/archive/pr2600.bak | git fast-import (import the new csets)
and what I get is:
progress Analyzing baseline repo ../domestic/product-reveal-1-26
progress 26434 csets already imported
progress Processing files
progress Processing changes
fatal: Not a valid commit: 63180d9d1614b02ae1fb3953a9a36f356f2451ff
fast-import: dumping crash report to .git/fast_import_crash_18546
I can certainly get you the crash report. But what’s interesting is that if I do a non-incremental fast-export (that is, treat this 1-2600 repo just like the 1-26 baseline) all the csets fast-import just fine. So it’s not really a “bad” commit, right, or I’d get the same error on a full export/import?
I might be misunderstanding something about the incremental export, or just missing a step. If you have any time to think about this and see if I’m just doing something stupid, I’d appreciate any hints!
So, never mind - I think I figured out how I was being stupid.
I didn’t have the prior git history in my “clean” repo - if I just did a cp -r …/product-reveal-1-26/.git .git it brought in all the old history. After that, the git fast-import worked just fine.
As is often the case, just writing out my plea for help clarified things enough. But thanks for your help retroactively!