Which warning are you getting? I am guessing it is this one:
fprintf(stderr,
"================================================================\n"
"sane: Warning: unable to obtain fully qualified hostname for this machine.\n"
"\"%s\" does not look like a valid domain name.\n"
"================================================================\n",
host);
We have struggled with how to deal with hostnames. Let me explain the purpose. To be distributed, BitKeeper
needs to assure that file deltas and changesets that are created in parallel are unique. So every object has a KEY associated with it that looks something like this:
$ bk prs -hnd:KEY: -r+ sane.c
ob@work.bitkeeper.com|src/sane.c|20160225222036|38735
That key is the unique identifier for the top delta on the file ‘src/sane.c’ in my current tree. The fields are from who, where and when the object was created and are as follows:
- The account name of the user.
- The name of the machine
- The pathname of the file
- The time (1-second granularity, GMT timezone)
- A checksum of the data
The first 4 fields are expected to be unique. The way that is done is with the following assumption. Every bk running with the same USER@HOST shares the same home directory. So in $HOME/.bk
we maintain a “uniqdb” of recent keys that have been created by this user. So if the user tries to create the same file in two different repositories during the same second, it notices and forces a 1-second fudge to the time of the later delta to keep the keys unique.
So the user@host that bk maintains is not an email address, but an identifier of where the cset was created.
In corporate environments where BitKeeper has typically been used a unique hostname for every machine is pretty reasonable and so the code asserts the machine must have a fully qualified hostname. For home users, it may not be true that a domain name exists for this machine.
We have a couple different proposals internally on how to address this, and if people are interested we could expand on this later.
The inconsistent part you are seeing is what I consider a bug in bk’s GUI code. That code works by calling bk to do various operations and in addition to using the exit code to determine success it generally looks for unexpected output as an indication of failure, so in this case, the warning became a failure.