Inconsistent hostname check


#1

When the host name is invalid some commands work with a warning, but bk citool just exits after displaying it. This breaks automatic merging with bk pull. Manual merging with bk resolve -T works fine.

This is on 32-bit Linux with BK 7.2.1ce compiled from source.


#2

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:

  1. The account name of the user.
  2. The name of the machine
  3. The pathname of the file
  4. The time (1-second granularity, GMT timezone)
  5. 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.


#3

Thanks for the detailed explanation! It will be very useful for the new BK users and could go straight into tutorial. Yes, I read the documentation and design notes and understand the BK data model, but such elaborated examples gathered in one place would be even better. Of course, for the BK developers it looks obvious but it’s not so for people alien to the BK workflow. The BK file history is more powerful and complex than in Git, so it needs more examples. It’s true that a newbie coming from a Git camp could become confused when e.g. he locks the file for editing and later changed his mind. There is no suggestion that he should unedit the file to make a commit.

Actually, the documentation needs some caring. There is some obsolete information scattered here and there, like e.g. bk filetypes pretends that repository files should have prefixes, while in the new version there are suffixes instead.

In general it would be very useful to make a cheat sheet of BK commands which are equivalent to Git.


#4

A post was split to a new topic: Git to BitKeeper Cheatsheet