r1 - 2004-11-03 - 12:45:00 - RobDayYou are here: NTP >  Dev Web > BitKeeperNotes > BkTerminology
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.

Please see the NTP Security Notice for vulnerability and mitigation details.

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.

source code control system, the underlying source code management (SCM) system that keeps track of file revisions. 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 SCCS/ 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 SCCS/ directory, whose name might be something like s.foo.c. 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 foo.c. It's the gfile that you'd do all your work on.

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 changes you've made to a gfile that you've checked out/edited -- it's the difference between the current sfile and the copy you're working with, before anything has been checked back in. If you edit a file and just save those changes from the editor, that file now has a corresponding diff. If you edit the file again and make more changes and save those additional changes, then the file has a larger diff -- it doesn't have two diffs. Again, this is before you've made any decision to save those changes.

Once you've decided that you like the editing changes you've made to a file, you can check it in which will update its corresponding sfile in the SCCS/ directory. Once you do that, the file no longer has a "diff" since your checked-out version agrees with that files's sfile. (Note that just checking in a file still doesn't mean you're committing to it. That comes shortly.)

Every time you check in a file, that file's revision number is incremented. If you were working with the file foo.c, revision 1.10, if you check it it, it's revision number will now 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.

After you make possibly multiple revisions to possibly multiple files, you can commit the result to your repo. This makes it official, and generates a new changeset for that repo which represents the sum total of all your changes files and their revisions.

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 foo.c, not just the last one.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r5 | r4 < r3 < r2 < r1 | More topic actions...
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback