sccschangeset(5)

📦 version 2022.10.16, in opensuse-leap 16.0

💅 sccschangeset — the vibe of a changeset file

okay so bestie, welcome to sccschangeset(5), which is a file formats page from the sccschangeset manual — the whole tea on what an SCCS changeset file even is. buckle up 🎀

✨ NAME ✨

sccschangeset — literally just the format of an SCCS changeset file. that's it, that's the name. 💖

🌸 DESCRIPTION 🌸

so an SCCS changeset file is an ASCII file that's basically a list of entries describing the state of a project set under the control of SCCSv6 or later. periodt.

and here's the iconic part: the changeset file itself is under control of SCCS. SCCS works directly on the s.changeset file. you never have to check out the related file content, because the deltas can be constructed without explicitly running the diff(1) program. that's a noticeable performance win, no cap 🔥 — it's giving efficiency, it's giving main character energy.

some of the information lives inside the changeset file content, and some of it lives within the SCCS meta data of the changeset file. both. at once. she contains multitudes ✨

🦋 Conventions

these are the terms used in this documentation, bestie — memorize them, they come up:

  • project set — a set of one or more files under control of SCCS that form a project.
  • project set home — a directory that is above all files from the related project set. this directory holds a directory .sccs with project set related meta data such as the changeset file, and typically the SCCS history files related to the project.
  • commit set — a single set of changes into the repository for a project set.
  • committer — the person who formed a commit set.
  • email address — the email address used to identify a committer. since the email address is valid for a whole commit set, it is recorded in the meta data of the related delta to the changeset file.

💜 File Format

each commit set adds a number of entries to the beginning of the changeset file — one entry for every file that was modified by this commit set. newest stuff on top, iykyk.

each entry describes the new state of a single file after it was modified, renamed, removed or restored in a related commit set.

each entry ends in a newline character. and ok this is the funky part — if the file name from the related file contains a newline character, then additional newlines may be in the related entry. 🫠 yes really.

each entry consists of five fields that are specific to a single file from the changeset. the entries are separated by a vertical bar character (ASCII 0x7C). and the vertical bar character may appear in the path name too, which is why the path name is last — slay, she's self-describing 🌈

the fields appear in this order:

  • urand — a unified pseudo random number that's used to help identify single files across renames during the lifetime of the sccs history. this unified random number is unique to any file from the project set. peep sccsfile(5) for a detailed description of the unified pseudo random number. the minimal length for it is thirteen hexadecimal characters; if the number could be represented with less digits, it's left filled with zeroes. this allows one to have a unique length for this number until Mar 31 10:55:07 2155 GMT. yes bestie, the year 2155. future-proof queen 👑
  • sid — the file specific SID that was used for the file mentioned in that line of the changeset.
  • sid-sum — the SID specific checksum for the related file. see sccsfile(5) for a detailed description of the SID specific checksums for a file.
  • path length — a decimal number representing the number of bytes in the path name not including the final newline character used to terminate the whole entry.
  • path name — the path name of the related file after the commit has been applied. it holds a relative path as seen from the project set home directory. and because the path name is the last member in the lines of a changeset file, it may contain the vertical bar character (ASCII 0x7C). 💅

a typical entry may look like this, and ngl she's gorgeous:

0e31666e43286|1.3|45206|15|some/dir/file.c

🎀 FILES 🎀

the sccs init command creates an initial framework of directories and files that allow to maintain a set of files in project mode. this is the directory structure it creates:

  • projecthome/.sccs/ — the location of SCCS files in case that SCCS is in project mode.
  • projecthome/.sccs/data — the location of the SCCS off-tree shadow directory tree that holds the history files for all files under control of SCCS when in project mode.
  • projecthome/.sccs/dels — the location of the history files from deleted files that have been in the repository.
  • projecthome/.sccs/SCCS/s.changeset — the project specific changeset file is in the directory .sccs in the project set home directory. this is the central database that allows one to retrieve the relation between project versions and file specific versions. only the s.changeset file is present, a related g-file does not exist. 🙈

🌟 SEE ALSO 🌟

go read these too, they're all icons:

sccs(1), sccs-admin(1), sccs-cdc(1), sccs-comb(1), sccs-cvt(1), sccs-delta(1), sccs-get(1), sccs-help(1), sccs-log(1), sccs-prs(1), sccs-prt(1), sccs-rmdel(1), sccs-sact(1), sccs-sccsdiff(1), sccs-unget(1), sccs-val(1), bdiff(1), diff(1), what(1), sccsfile(5).

💀 BUGS 💀

None currently known. not a single one. flawless behavior fr fr 🧚

mail bugs and suggestions to schilytools@mlists.in-berlin.de or open a ticket at https://codeberg.org/schilytools/schilytools/issues. 🫶

the mailing list archive may be found at:

https://mlists.in-berlin.de/mailman/listinfo/schilytools-mlists.in-berlin.de

ok that's the whole page, bestie!! 💖✨ this little manual page is sccschangeset(5), written by Joerg Schilling, dated 2022/10/06 — go forth and read your changeset files with confidence, mwah 🎀💅🍓

📦 where this page comes from