On Apr 18, 2024, at 1:41 PM, Dan Cross <cro...@gmail.com> wrote:
>
> Culturally, there was a feeling that source revision a la RCS, SCCS,
> etc, were unnecessary because the dump filesystem gave you snapshots
> already. Moreover, those were automatic and covered more than one file
> at a time; RCS/SCCS required some discipline in that one had to
> remember to check in a new revision. And as Paul said, the idea of an
> atomic, multi-file changeset was revolutionary at the time.
Readers here may be interested in our experience (circa 1982!)
At Fortune Systems, in 1982, Dave Yost come up with "cloned
tree" system for source code control. The idea was, each
developer gets their own src tree where all the files are
initally hard linked with the mastr tree (& are readonly). We
modified vi to always save the old file foo as ,foo and write
out a new file foo. [Note that the Rand editor e which many
of us used already did this.] This makes it easy to see that
files with link count == 1 are modified locally. When some
feature / bugix is complete, someone would manually "commit"
changes to the "master" branch using diff to review them.
Dave wrote a paper about this called "A Rich Man's SCCS" in
Usenix Summer 1985.
Looking back, we had some (fuzzy) idea of a change set. But
we didn't have a way to keep a log of what changed and why.
And we didn't automate "commit". We did have a way of naming
top level trees ("frozen" ones by the date of the latest
modified file, development ones by the version we were
working on + developer name). We also modified tar to allow
saving and restoring a set of trees (recreating links for
identical files).
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-Me7d866a5dbc8db8e84dd93be
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
