NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p15
was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
Most of what follows can also be found under
bk helptool terms
. I just wanted to restructure it slightly for the audience I'm writing it for but, yes, I shamelessly stole chunks of this straight from the helptool page. I've ordered these definitions so that it makes sense to read them top down. (If you think there are commands that would be useful to run in order to better understand any of these definitions, feel free to add them.)
package,
repository: A
package represents a
logical collection of files, like the Linux 2.6.8 kernel package, or the gcc-3.3.4 package. A
repository represents an
instance of that package, so a single package might be represented by numerous repositories out there, each with its own developer making his own changes. A repository is also sometimes called a
work space or a
clone.
identity: There are two kinds of identities. Each BK package has a unique
package identity that is the same across all copies or instances of that package, while each repository has its own
repository identity, regardless of its underlying package. You can list each of these identities with:
$ bk id # package identity
$ bk id -r # repository identity
SCCS:
Source Code Control System, the underlying source code management (SCM) system used to keep track of the actual files and directories and their revision history. When you first clone a repository, chances are none of the files will be visible in their
regular locations, but their internal SCCS files will be in their respective
SCCS/
directories. To work with a file, you'd normally check it out or edit it.
gfile,
sfile: A
gfile (or "gotten" file) is the regular file name that would be used by a developer, like
foo.c
, while the
sfile (or sometimes
s.file) is the underlying SCCS file representing that file and all of its revision history, which you would find in the corresponding file
SCCS/s.foo.c
. If you wanted to examine or do some work on a file, you'd first have to
check out or
edit that file, which would create the
gfile from its corresponding
sfile. If you really want to see a directory's sfiles without actually checking anything out, just run:
$ ls SCCS
in that directory.
extras: This generally refers to files in your repository that aren't under any revision control; that is, perhaps temporary junk that you may have created but have no intention of checking in. You can see these files with the command:
$ bk extras
check out,
edit: When you want to either examine or make changes to a file, you would normally
check out or
edit the
sfile to get the corresponding
gfile. It seems traditional to say that, if you just want to examine a file in read-only mode, you'd "check it out", while if you want to get the file in writable form to make changes to it, you'd talk of "editing" the file, but this difference in terminology is not cast in stone.
diff: The word
diff is generally used to describe the difference between a file's
sfile, and its checked out
gfile. If you edit a file, make some changes and just save those changes to your current gfile form of that file, that file now has a diff. Note that this is before you check any changes back in. If you pop back into the editor, make more changes and save the file again, the diff for that file will now be larger, but it will still be considered as one diff, not two smaller diffs.
To see all of the current diffs in a repo, just type:
$ bk -r diffs
check in: Once you've decided that you like the changes you've made to a file and saved from the editor, you can
check it in, which will update the corresponding sfile in the
SCCS/
directory and increment its
revision number. Once you do that, the file is no longer considered to have a "diff" since your edited version agrees with the sfile in the
SCCS/
directory. (Note carefully that just checking in a file doesn't mean you're committing to it just yet. That comes later. Keep reading.)
revision,
delta: When you check in an updated copy of a file, this increments its
revision number. You might also refer to any given revision of a file as a
delta of that file, but that depends on the context. The word "delta" might refer to a specific revision of a file, or it might be used to represent the
difference between a version of a file and its previous version. Again, it's all based on the context.
If you want a quick summary of a file's revision history, just type something like:
$ bk prs README
and see the helptool page for
bk prs
for more options.
pending: This term refers to files that have been checked out, edited and modified and saved, and checked in, but not yet committed to a changeset. If you want to see everything that's currently pending, just type:
$ bk pending
commit: After you edit possibly multiple files, make changes and check those files back in, you can commit all of those changes, which generates a new
changeset. As we've already mentioned, you can get a list of all of your currently-uncommitted but checked-in changes with:
$ bk pending
cset,
changeset,
ChangeSet: A
changeset (also abbreviated
cset) is a collection of files and their revisions that are logically related, and that represent the unit of repository modification that is exchanged between repositories (well, that and
patches). Normally, you'd group a collection of file revisions into a changeset because they represent a single, functional change or improvement to the repository, like "Upgraded USB support to 2.0".
Note that it's possible for a file to have more than one revision in a single changeset. If you edited file
foo.c
, figured you were done with it and checked it in, it might get a new revision number of, say, 1.11. If you realize you forgot something in that file, re-edited it, saved it and checked the newer version in, it would get the revision number 1.12. If you then committed that file as part of a new changeset, that changeset would contain
both revisions of that file.
If you want some brief information on your repo's changesets, try any of the following:
$ bk changes -r+ -nd:REV: # latest changeset revision number
$ bk changes -r+ # general purpose of last changeset
$ bk changes -r<rev number> # general purpose of a given changeset
Finally, the changeset history of a repository is stored in the file named
ChangeSet
.
key: A
key is a unique, unchanging identifier for a version of a file that can be used anywhere a regular version or revision number for that file can be used. You can extract the key for a particular file revision in one of two ways, depending on the key format that you want; for example:
$ bk prs -hr<rev> -nd:KEY: Makefile # human readable
$ bk prs -hr<rev> -nd:MD5KEY: Makefile # not so human readable
NOTE: The
bk helptool terms
page shows a different version of the above commands:
$ bk -R prs -hr<rev> -nd:KEY: Makefile
$ bk -R prs -hr<rev> -nd:MD5KEY: Makefile
The
-R
option means that the command will be run relative to the root of the repository, which is probably not what you want if you happen to be in a subdirectory somewhere.
tag,
symbol: A
tag or
symbolic name can be given to any revision of your repository, so you can associate a meaningful name with some snapshot of the repo. You can get a list of all of the tags in your current repo with:
$ bk tags
which is just a short form for
bk changes -t
, actually.