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.
Feel free to correct/update any of the following terminology.
: A hierarchical collection of revision files, sometimes just called a "tree" or a "repo" for short. This is what you'll almost certainly clone and work with, making editing changes and possibly pushing your changes back to the parent repository from which you cloned in the first place.
: Source Code Control System
, the underlying source code management (SCM) system that keeps track of the actual files and their numerous revisions in a repository. When you first clone a repo, chances are none of the files will be visible in their regular
locations, but their SCCS files will be in their corresponding
directory. To work with a file, you'd normally check it out or edit it.
: An "sfile" (or "s.file") is the term used to describe the versioned form of a file that's stored in the
directory, whose name might be something like
. If you want to work with that file, you'd normally check it out or edit it, at which point you'd get a regular "gfile" (or "gotten" file) form of the file, whose name would be just
. It's the gfile that you'd do all your work on.
If you want to see the sfiles, from any directory, just run:
$ ls SCCS
: This generally refers to files in the tree that aren't under any revision control. That is, temporary junk that you may have created and have no intention of checking in or committing.
: When you want to either examine or make changes to a file, you would normally check out or edit the s.file
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.
: The word diff
is used to describe the difference between a file's sfile, and its current edited version. 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
: Once you've decided that you like the changes you've made to a file, you can check it in
, which will update the corresponding sfile in the
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
directory. (Note carefully that just checking in a file doesn't mean you're committing to it just yet. That comes later. Keep reading.)
If you want to see all of the currently-uncommitted changes that you've checked in so far, just type:
$ bk pending
: Every time you check in a file, that file's revision number is incremented. If you were working with the file
, revision 1.10, make some changes and check it in, its sfile will be updated and its revision number will increase to 1.11. At this point, you can recheck it out, start all over again with new changes, and check the new changes in again
, which will generate revision 1.12 of the file. As I read it, the word "delta" represents the change between consecutive revisions, but I might be wrong.
If you want a quick summary of a file's revision history, just type something like:
$ bk prs README
: 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
: A changeset is a collection of files and their revisions that are logically related, and is the unit of repo modification that is exchanged between repositories. A changeset will typically contain one or more files, and possibly more than one revision of the same file. For example, if you look at the example in the definition of a revision or delta above, and you committed these changes to a changeset, that changeset would contain both
revisions 1.11 and 1.12 of the file
, not just the last one.
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