EditWYSIWYGAttachPrintable
r4 - 2004-11-04 - 17:30: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.8p14 was released on 03 March 2020. It addresses 2 medium-severity security issues in ntpd, and provides 47 non-security bugfixes and 4 other improvements 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.
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.

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.

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, 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 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.

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, look at the context.

If you want a quick summary of a file's revision history, just type something like:

 $ bk prs README

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. The new changeset you create 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:

 $ bk -R prs -hr<rev> -nd:KEY: <filename>       # human readable
 $ bk -R prs -hr<rev> -nd:MD5KEY: <filename>    # not so human readable

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
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-2020 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