6 ms·

SCCS: The Posix Standard Source Code Control System (2017)

55 points by beefhash 8y ago

arka2147483647 8y ago
Is this just a historic artifact, or does it have some practical use?
- andrew_ 8y ago
  I'd wager historical artifact. The feature set in git alone steamrolls SCCS, and concurrency methods have decidedly moved away from lock in favor of merge. There's also been little activity in the last three years or so. I'd also wager there are still some good uses for it, and it's probably enjoying use by some folks still, but it looks like it's gone the way of CVS.
  - janoc 8y ago
    Actually this is a real relic (started in 1972!). The original open source (SCCS used to be proprietary) RCS tool that predates CVS (CVS was built on top of RCS) was meant as an alternative to SCCS, with similar functionality. SCCS was horrible, even by CVS standards. I had the "pleasure" of using this on HP UX back in the day and it wasn't fun at all. * File oriented, there is no concept of an atomic commit, change set or anything similar, every file is independently tracked - so your commit may fail halfway (e.g. because of a conflict) and the repo is left in an inconsistent state, with some files having their changes applied and some not. RCS and CVS have inherited this wonderful design trait too. One of major Subversion improvements over CVS was introduction of atomic commits that either succeed or fail but not break halfway. * Locking. Yay. You checked out a file, it got locked. If you forgot about it and e.g. went on vacation or something, everyone else was screwed until you came back ... Even CVS was not working in this way. * Frequent file corruption. Hacking the ,v files was frequent, sometimes you had to do it as root (e.g. in the above-mentioned case of a colleague on vacation leaving a file locked). Hopefully you had good backups ... * Yay for the wonderful "comma vee" extension that meant this didn't work on anything but Unix and even there some tools choked on it. Same for RCS and CVS ... * No way to access the repository remotely, except over NFS, with all the associated problems. SCCS (and RCS) were really meant to version individual files, such as system configuration files. There it was working relatively OK. However, using this for actual source code on a larger project with multiple developers was a pure masochism. I can't imagine anyone using this today. Even CVS runs circles around it, not to mention Subversion, Git or Mercurial.
    - russfink 8y ago
      This. Thanks, I forgot about SVN!
    - deleted 8y ago
      [deleted]
    - lscotte 8y ago
      If I'm not mistaken, one more is that the only fully stored file in SCCS is the first commit, from them on its just the deltas. Checking out a lot of files with a long commit history could take a while on the old hardware we had back when SCCS was more common. RCS improved in this by doing the reverse: the latest file is fully stored and deltas go backwards in time. Again, that's if memory serves correctly...
      - dfox 8y ago
        You are mistaken, while it is true that first revision is stored essentially as-is, this ceases to be true when you create another revision. SCCS stores all the revisions interwoven in single file (the format is called weave) by tracking on per-line basis the range of revisions that contained such line.
    - _kst_ 8y ago
      "Yay for the wonderful "comma vee" extension that meant this didn't work on anything but Unix and even there some tools choked on it. Same for RCS and CVS ..." RCS and CVS use "filename,v". SCCS uses "s.filename".
  - ansible 8y ago
    Yep. It is kind of amusing how tracking history has evolved over the years. We started out with an initial version (of a file) and then tracking the changes since the beginning. One of the major innovations with RCS was to track changes in reverse time, so that the latest version of the file was quickly accessible. And with git and other DVCS, we're back to forward-time tracking of changes, but now with snapshots along the way to easily produce the current version on a branch. While it's amusing to see someone still working on it, for new projects, if I was interested in not using git, I'd likely go for fossil just because it integrates many other useful tools like issue tracking. It is unfortunate that an integrated issue tracking never seemed to get widespread adoption in the git world.
    - jimktrains2 8y ago
      Git doesn't store deltas, it stores the whole object for each version of the file.
      - wolfgang42 8y ago
        In theory, Git doesn't store deltas. In practice, it uses packfiles which store some objects as diffs against other objects. (As I understand it, though, it doesn't do this strictly by time, it has some heuristics to find the most similar other object which may pick completely unrelated objects if they're similar enough.)
        jimktrains2 8y ago
        My understanding is that that's an optimization for space and only used for much older commits. Pack files aren't needed in or present in every repository. They're more an archive than part of everyday usage is my understanding.
- beefhash 8y ago
  I think it's somewhere inbetween, similar to the heirloom-doctools. You can interact with any live SCCS repo -- if you find any outside of BitKeeper (whose format seems to have diverged anyway). And for some reason it's in POSIX. I'm pretty sure nobody even cares about its existence in POSIX, but it's technically there. Though I can't think of a single OS that ships SCCS; OpenBSD ships GNU CVS and their own RCS (OpenCVS is sadly in eternal limbo[1]), not sure what FreeBSD does. Linux distributions generally don't ship anything. And git has basically won anyway. [1] http://openbsd-archive.7691.n7.nabble.com/Status-of-OpenCVS-td318199.html http://openbsd-archive.7691.n7.nabble.com/Status-of-OpenCVS-...
  - pjmlp 8y ago
    > Though I can't think of a single OS that ships SCCS Commercial UNIX systems do. Check the documentation of Aix, HP-UX and similar.
    - deleted 8y ago
      [deleted]
  - AdieuToLogic 8y ago
    Recent FreeBSD's do not, though the what[0] command has been ported from SCCS and is, IMHO, the only part of SCCS which remains relevant. 0 - https://www.freebsd.org/cgi/man.cgi?query=what&apropos=0&sektion=0&manpath=FreeBSD+11.2-RELEASE&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=what&apropos=0&sek...
  - anthk 8y ago
    I think OpenBSD switched to its own CVS binary. EDIT: So, not yet, but they will. OpenBSD has a long story of reimplementing GNU tools in BSD, see the bc(1), dc(1) history.
    - beefhash 8y ago
      Work on OpenCVS started in 2004[1] and schwarze@ said last year that the project is "dormant" and in a state where "trying to use it in production revealed instabilities that were non-trivial to debug, and nobody did the work to get if from 'almost ready' to 'reliable'." [1] https://bsd.slashdot.org/story/04/12/06/1154242/new-bsd-licensed-cvs-replacement-for-openbsd https://bsd.slashdot.org/story/04/12/06/1154242/new-bsd-lice... [2] https://marc.info/?l=openbsd-misc&m=149453183500614&w=2 https://marc.info/?l=openbsd-misc&m=149453183500614&w=2
- kchoudhu 8y ago
  I migrated the mortgage desk of a major investment bank off SCCS in 2010. These old tools are more common than the cool kids would have you believe.
  - canhascodez 8y ago
    A single department of one organization, eight years ago, which you migrated to something else? You seem to be contradicting yourself. Any current use of SCCS would exceed my expectations, but I'm quite confused by your example.
    - kchoudhu 8y ago
      Even in tech, 8 years is not a long time. When I said that there was SCCS in use at a major bank in 2010, the hope therefore was that the reader would think "that probably means that SCCS is in use elsewhere".
- smarks 8y ago
  From my point of view this is primarily a historic artifact, with limited practical use. As I mentioned in another comment, my projects (at Sun in the 1980s and 1990s) used SCCS on shared filesystems. For day to day work everything has long since moved to other VCSes such as Git and Mercurial. The JDK sources were maintained in SCCS (which was wrapped within CodeManager/Teamware) prior to being open sourced in 2007. The history in the OpenJDK repositories goes only back to that time. The (Oracle internal) archives of previous versions of the JDK, which date to before JDK 1.0, are still in SCCS format. I'll occasionally browse through the ancient history of these sources using Schily's SCCS implementation. What's cool is that all my old shell aliases and functions still work. Of course this is browsing/viewing only. I haven't checked in an edit using SCCS in decades.
russfink 8y ago
I started with SCCS, then moved to RCS, then to CVS for a long while. I'm now an occasional Git user. The number one problem with SCCS is a locked checkout paradigm: one person gets to edit at a time. Also, it doesn't manage directories, only files. Read here for some alternatives: https://en.m.wikipedia.org/wiki/Comparison_of_version_control_software https://en.m.wikipedia.org/wiki/Comparison_of_version_contro...
- masklinn 8y ago
  > The number one problem with SCCS is a locked checkout paradigm That's common amongst the older breed of VCS: VSS or Perforce do the same. It's useful when working on binary files which can't be merged. Some centralised VCS (e.g. SVN) can be opted into locked checkout on a per-file basis. Definitely not a great default though.
  - Arnt 8y ago
    It depends. I've worked with both SCCS, RCS, Perforce and git. The way SCCS and RCS did it was a pain, but Perforce's was IMO more feature than bug. When Perforce told me "uh, X is editing this file you're just about to edit", talking to X was usually a good idea for some reason I wasn't aware of. Sometimes X was working on one issue and I on another, and the deeper cause was actually the same. Sometimes X had forgotten to check in some work and would do so immediately when I asked. Not always. But often enough that I liked those locks. (Hated the RCS/SCCS locks though. Those had far too much cost and offered too little value.)
  - agapon 8y ago
    p4 edit does not do that by default. But it can be done with explicit p4 lock.
  - setquk 8y ago
    Sometimes locking out files on complex changes has a better outcome than a modify-merge cycle I have found. This doesn't scale out to lots of engineers however. If you're doing critical heavy lifting or refactoring, merging inline changes is hell.
saxonww 8y ago
There's also a GNU replacement CSSC[0]. I had to set this up at work 6-7 years ago to handle a very old code base that no one wanted to modernize. The repo was delivered to me on an old SCO system. I was able to move it to a modern system using CSSC, where it still lives today and needs almost no attention. One benefit of these ancient tools is that they are effectively done. They've been beaten on for years; all behavior and quirks are well understood, and whatever the promised feature set is, usually exists and works exactly as promised. [0]: https://www.gnu.org/software/cssc/ https://www.gnu.org/software/cssc/
- setquk 8y ago
  They're also extremely easy to conceptualise and use.
dfox 8y ago
One notable thing about SCCS is that it in fact played important role in creation of git as BitKeeper is direct descendant of SCCS.
qwerty456127 8y ago
Pragmatically, why would anybody need anything but git nowadays?
- tannhaeuser 8y ago
  1. git, until very recently (but haven't checked), requires you to check out the whole repo even if you're just interested in only a subdir or single file 2. Suppose you're implementing a Wiki where docs are version-controlled on a fs mounted by the web server. git doesn't really fit this use case since you'd need a shared checkout dir, whereas eg. RCS does, provided locking is accepted or even preferred 3. on-site version control of config files in /etc when you don't do full-blown DevOps
- grkvlt 8y ago
  Because they want a DVCS that has less characters in its name, to save on typing? Mercurial [0] is a fairly popular choice these days, I believe, and uses 'hg' as its command line tool. 0. https://www.mercurial-scm.org/ https://www.mercurial-scm.org/

55 points by beefhash 8y ago

arka2147483647 8y ago

Is this just a historic artifact, or does it have some practical use?

andrew_ 8y ago
I'd wager historical artifact. The feature set in git alone steamrolls SCCS, and concurrency methods have decidedly moved away from lock in favor of merge. There's also been little activity in the last three years or so. I'd also wager there are still some good uses for it, and it's probably enjoying use by some folks still, but it looks like it's gone the way of CVS.
- janoc 8y ago
  Actually this is a real relic (started in 1972!). The original open source (SCCS used to be proprietary) RCS tool that predates CVS (CVS was built on top of RCS) was meant as an alternative to SCCS, with similar functionality. SCCS was horrible, even by CVS standards. I had the "pleasure" of using this on HP UX back in the day and it wasn't fun at all. * File oriented, there is no concept of an atomic commit, change set or anything similar, every file is independently tracked - so your commit may fail halfway (e.g. because of a conflict) and the repo is left in an inconsistent state, with some files having their changes applied and some not. RCS and CVS have inherited this wonderful design trait too. One of major Subversion improvements over CVS was introduction of atomic commits that either succeed or fail but not break halfway. * Locking. Yay. You checked out a file, it got locked. If you forgot about it and e.g. went on vacation or something, everyone else was screwed until you came back ... Even CVS was not working in this way. * Frequent file corruption. Hacking the ,v files was frequent, sometimes you had to do it as root (e.g. in the above-mentioned case of a colleague on vacation leaving a file locked). Hopefully you had good backups ... * Yay for the wonderful "comma vee" extension that meant this didn't work on anything but Unix and even there some tools choked on it. Same for RCS and CVS ... * No way to access the repository remotely, except over NFS, with all the associated problems. SCCS (and RCS) were really meant to version individual files, such as system configuration files. There it was working relatively OK. However, using this for actual source code on a larger project with multiple developers was a pure masochism. I can't imagine anyone using this today. Even CVS runs circles around it, not to mention Subversion, Git or Mercurial.
  - russfink 8y ago
    This. Thanks, I forgot about SVN!
  - deleted 8y ago
    [deleted]
  - lscotte 8y ago
    If I'm not mistaken, one more is that the only fully stored file in SCCS is the first commit, from them on its just the deltas. Checking out a lot of files with a long commit history could take a while on the old hardware we had back when SCCS was more common. RCS improved in this by doing the reverse: the latest file is fully stored and deltas go backwards in time. Again, that's if memory serves correctly...
    - dfox 8y ago
      You are mistaken, while it is true that first revision is stored essentially as-is, this ceases to be true when you create another revision. SCCS stores all the revisions interwoven in single file (the format is called weave) by tracking on per-line basis the range of revisions that contained such line.
  - _kst_ 8y ago
    "Yay for the wonderful "comma vee" extension that meant this didn't work on anything but Unix and even there some tools choked on it. Same for RCS and CVS ..." RCS and CVS use "filename,v". SCCS uses "s.filename".
- ansible 8y ago
  Yep. It is kind of amusing how tracking history has evolved over the years. We started out with an initial version (of a file) and then tracking the changes since the beginning. One of the major innovations with RCS was to track changes in reverse time, so that the latest version of the file was quickly accessible. And with git and other DVCS, we're back to forward-time tracking of changes, but now with snapshots along the way to easily produce the current version on a branch. While it's amusing to see someone still working on it, for new projects, if I was interested in not using git, I'd likely go for fossil just because it integrates many other useful tools like issue tracking. It is unfortunate that an integrated issue tracking never seemed to get widespread adoption in the git world.
  - jimktrains2 8y ago
    Git doesn't store deltas, it stores the whole object for each version of the file.
    - wolfgang42 8y ago
      In theory, Git doesn't store deltas. In practice, it uses packfiles which store some objects as diffs against other objects. (As I understand it, though, it doesn't do this strictly by time, it has some heuristics to find the most similar other object which may pick completely unrelated objects if they're similar enough.)
      - jimktrains2 8y ago
        My understanding is that that's an optimization for space and only used for much older commits. Pack files aren't needed in or present in every repository. They're more an archive than part of everyday usage is my understanding.
beefhash 8y ago
I think it's somewhere inbetween, similar to the heirloom-doctools. You can interact with any live SCCS repo -- if you find any outside of BitKeeper (whose format seems to have diverged anyway). And for some reason it's in POSIX. I'm pretty sure nobody even cares about its existence in POSIX, but it's technically there. Though I can't think of a single OS that ships SCCS; OpenBSD ships GNU CVS and their own RCS (OpenCVS is sadly in eternal limbo[1]), not sure what FreeBSD does. Linux distributions generally don't ship anything. And git has basically won anyway. [1] http://openbsd-archive.7691.n7.nabble.com/Status-of-OpenCVS-td318199.html http://openbsd-archive.7691.n7.nabble.com/Status-of-OpenCVS-...
- pjmlp 8y ago
  > Though I can't think of a single OS that ships SCCS Commercial UNIX systems do. Check the documentation of Aix, HP-UX and similar.
  - deleted 8y ago
    [deleted]
- AdieuToLogic 8y ago
  Recent FreeBSD's do not, though the what[0] command has been ported from SCCS and is, IMHO, the only part of SCCS which remains relevant. 0 - https://www.freebsd.org/cgi/man.cgi?query=what&apropos=0&sektion=0&manpath=FreeBSD+11.2-RELEASE&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=what&apropos=0&sek...
- anthk 8y ago
  I think OpenBSD switched to its own CVS binary. EDIT: So, not yet, but they will. OpenBSD has a long story of reimplementing GNU tools in BSD, see the bc(1), dc(1) history.
  - beefhash 8y ago
    Work on OpenCVS started in 2004[1] and schwarze@ said last year that the project is "dormant" and in a state where "trying to use it in production revealed instabilities that were non-trivial to debug, and nobody did the work to get if from 'almost ready' to 'reliable'." [1] https://bsd.slashdot.org/story/04/12/06/1154242/new-bsd-licensed-cvs-replacement-for-openbsd https://bsd.slashdot.org/story/04/12/06/1154242/new-bsd-lice... [2] https://marc.info/?l=openbsd-misc&m=149453183500614&w=2 https://marc.info/?l=openbsd-misc&m=149453183500614&w=2
kchoudhu 8y ago
I migrated the mortgage desk of a major investment bank off SCCS in 2010. These old tools are more common than the cool kids would have you believe.
- canhascodez 8y ago
  A single department of one organization, eight years ago, which you migrated to something else? You seem to be contradicting yourself. Any current use of SCCS would exceed my expectations, but I'm quite confused by your example.
  - kchoudhu 8y ago
    Even in tech, 8 years is not a long time. When I said that there was SCCS in use at a major bank in 2010, the hope therefore was that the reader would think "that probably means that SCCS is in use elsewhere".
smarks 8y ago
From my point of view this is primarily a historic artifact, with limited practical use. As I mentioned in another comment, my projects (at Sun in the 1980s and 1990s) used SCCS on shared filesystems. For day to day work everything has long since moved to other VCSes such as Git and Mercurial. The JDK sources were maintained in SCCS (which was wrapped within CodeManager/Teamware) prior to being open sourced in 2007. The history in the OpenJDK repositories goes only back to that time. The (Oracle internal) archives of previous versions of the JDK, which date to before JDK 1.0, are still in SCCS format. I'll occasionally browse through the ancient history of these sources using Schily's SCCS implementation. What's cool is that all my old shell aliases and functions still work. Of course this is browsing/viewing only. I haven't checked in an edit using SCCS in decades.

russfink 8y ago

I started with SCCS, then moved to RCS, then to CVS for a long while. I'm now an occasional Git user. The number one problem with SCCS is a locked checkout paradigm: one person gets to edit at a time. Also, it doesn't manage directories, only files. Read here for some alternatives: https://en.m.wikipedia.org/wiki/Comparison_of_version_control_software https://en.m.wikipedia.org/wiki/Comparison_of_version_contro...

masklinn 8y ago
> The number one problem with SCCS is a locked checkout paradigm That's common amongst the older breed of VCS: VSS or Perforce do the same. It's useful when working on binary files which can't be merged. Some centralised VCS (e.g. SVN) can be opted into locked checkout on a per-file basis. Definitely not a great default though.
- Arnt 8y ago
  It depends. I've worked with both SCCS, RCS, Perforce and git. The way SCCS and RCS did it was a pain, but Perforce's was IMO more feature than bug. When Perforce told me "uh, X is editing this file you're just about to edit", talking to X was usually a good idea for some reason I wasn't aware of. Sometimes X was working on one issue and I on another, and the deeper cause was actually the same. Sometimes X had forgotten to check in some work and would do so immediately when I asked. Not always. But often enough that I liked those locks. (Hated the RCS/SCCS locks though. Those had far too much cost and offered too little value.)
- agapon 8y ago
  p4 edit does not do that by default. But it can be done with explicit p4 lock.
- setquk 8y ago
  Sometimes locking out files on complex changes has a better outcome than a modify-merge cycle I have found. This doesn't scale out to lots of engineers however. If you're doing critical heavy lifting or refactoring, merging inline changes is hell.

saxonww 8y ago

There's also a GNU replacement CSSC[0]. I had to set this up at work 6-7 years ago to handle a very old code base that no one wanted to modernize. The repo was delivered to me on an old SCO system. I was able to move it to a modern system using CSSC, where it still lives today and needs almost no attention. One benefit of these ancient tools is that they are effectively done. They've been beaten on for years; all behavior and quirks are well understood, and whatever the promised feature set is, usually exists and works exactly as promised. [0]: https://www.gnu.org/software/cssc/ https://www.gnu.org/software/cssc/

setquk 8y ago
They're also extremely easy to conceptualise and use.

dfox 8y ago

One notable thing about SCCS is that it in fact played important role in creation of git as BitKeeper is direct descendant of SCCS.

qwerty456127 8y ago

Pragmatically, why would anybody need anything but git nowadays?

tannhaeuser 8y ago
1. git, until very recently (but haven't checked), requires you to check out the whole repo even if you're just interested in only a subdir or single file 2. Suppose you're implementing a Wiki where docs are version-controlled on a fs mounted by the web server. git doesn't really fit this use case since you'd need a shared checkout dir, whereas eg. RCS does, provided locking is accepted or even preferred 3. on-site version control of config files in /etc when you don't do full-blown DevOps
grkvlt 8y ago
Because they want a DVCS that has less characters in its name, to save on typing? Mercurial [0] is a fairly popular choice these days, I believe, and uses 'hg' as its command line tool. 0. https://www.mercurial-scm.org/ https://www.mercurial-scm.org/