3 ms·

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

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.

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.