From: Peter Seibel
Subject: File versioning on TOPS-20, et alia -- by diffs?
Date:
Message-ID: <m3fz20mqhe.fsf@javamonkey.com>
So back in the day when Real Operating Systems kept multiple versions
of files did they do it the way today's version control systems do, by
storing (reverse) deltas? Or did they just keep multiple copies around?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Bob Bechtel
Subject: Re: File versioning on TOPS-20, et alia -- by diffs?
Date:
Message-ID: <41C77461.9050803@comcast.net>
Multiple copies, if the effect on my disk quota under TENEX and TOPS-20
was to be believed.
Typically, you'd specify a policy, like keeping an original and only the
n most recent versions, rather than keeping every version - but keeping
every version was an acceptable policy, kept in check by the quota system.
bob bechtel
Peter Seibel wrote:
> So back in the day when Real Operating Systems kept multiple versions
> of files did they do it the way today's version control systems do, by
> storing (reverse) deltas? Or did they just keep multiple copies around?
>
> -Peter
>
Peter Seibel <·····@javamonkey.com> writes:
> So back in the day when Real Operating Systems kept multiple
> versions of files did they do it the way today's version control
> systems do, by storing (reverse) deltas? Or did they just keep
> multiple copies around?
As far as I know, multiple copies. On VMS (and I presume other
systems which supported this) it worked on all kinds of files; I'm not
sure when binary deltas were developed, or whether that would be
practical on systems which didn't necessarily regard all files as
untyped byte streams.
The GNU project always threatened to add file multiple file versions
to their system. Anyone know whether anything in Hurd actually does
that? Indeed, are there any modern systems which do (other than
OpenVMS, I guess)?
From: Christopher C. Stacy
Subject: Re: File versioning on TOPS-20, et alia -- by diffs?
Date:
Message-ID: <u1xdk1k74.fsf@news.dtpq.com>
Bruce Stephens <············@cenderis.demon.co.uk> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > So back in the day when Real Operating Systems kept multiple
> > versions of files did they do it the way today's version control
> > systems do, by storing (reverse) deltas? Or did they just keep
> > multiple copies around?
>
> As far as I know, multiple copies. On VMS (and I presume other
> systems which supported this) it worked on all kinds of files; I'm not
> sure when binary deltas were developed, or whether that would be
> practical on systems which didn't necessarily regard all files as
> untyped byte streams.
>
> The GNU project always threatened to add file multiple file versions
> to their system. Anyone know whether anything in Hurd actually does
> that? Indeed, are there any modern systems which do (other than
> OpenVMS, I guess)?
Open Genera :)
From: Will Hartung
Subject: Binary -> Source links (was Re: File versioning on TOPS-20, et alia -- by diffs?)
Date:
Message-ID: <32ragoF3p7doaU1@individual.net>
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> Bruce Stephens <············@cenderis.demon.co.uk> writes:
> > The GNU project always threatened to add file multiple file versions
> > to their system. Anyone know whether anything in Hurd actually does
> > that? Indeed, are there any modern systems which do (other than
> > OpenVMS, I guess)?
>
> Open Genera :)
Now, as I understand it, Open Genera also was able to link binaries to
source code (for debugging, etc.).
Any ideas how it managed relationships to files with multiple versions on
the disk? Did it track the file version as well as the file name in the
source link (in VMS you'd use "FILE.DAT;123" for an absolute reference)? If
I had a binary bit that was linked to an older source file, but had a more
recent source file (say a yet to be compiled work in progress), would Genera
go to the older file or the current file? If I simply re-evaluated a
function within a source file (say I added 10 lines to it), would the system
be out of sync with all of other functions located below the changed
function in the file until I rebuilt the entire file?
What about code that was simply keyed in to a listener, did Genera keep
track of that code as well?
Having never seen it in action, I don't know what its capabilities were, and
with the dynamics of source code change, and how only fragments of code
would be re-evaluated, I'm just curious how OG managed to pull it all off
(if it indeed did at all...).
Regards,
Will Hartung
(·····@msoft.com)
From: Christopher C. Stacy
Subject: Re: Binary -> Source links (was Re: File versioning on TOPS-20, et alia -- by diffs?)
Date:
Message-ID: <u1xdjmirg.fsf@news.dtpq.com>
"Will Hartung" <·····@msoft.com> writes:
> "Christopher C. Stacy" <······@news.dtpq.com> wrote in message
> ··················@news.dtpq.com...
> > Bruce Stephens <············@cenderis.demon.co.uk> writes:
> > > The GNU project always threatened to add file multiple file versions
> > > to their system. Anyone know whether anything in Hurd actually does
> > > that? Indeed, are there any modern systems which do (other than
> > > OpenVMS, I guess)?
> >
> > Open Genera :)
>
> Now, as I understand it, Open Genera also was able to link binaries to
> source code (for debugging, etc.).
>
> Any ideas how it managed relationships to files with multiple versions on
> the disk? Did it track the file version as well as the file name
The Lisp Machine used pathnames -- the ANSI CL pathname system is a small
subset of the functionality from the Lisp Machine. Pathnames of course
have a VERSION component. This association was maintained on each individual
Lisp object (eg. symbol or function) itself, not in some external
"tags" file, so it was always up to date.
> What about code that was simply keyed in to a listener,
> did Genera keep track of that code as well?
You could not type "meta-dot" and have it scroll the Listener
history, if that's what you mean.
> Having never seen it in action, I don't know what its capabilities
> were, and with the dynamics of source code change, and how only
> fragments of code would be re-evaluated,
The same way that you do it in current Lisp systems.
When you type a command to load a source file, or compile the
contents of an editor buffer or individual function, it would
update the information on the function.
In fact, isn't all this pretty much the same in those systems today?
From: Kalle Olavi Niemitalo
Subject: Re: File versioning on TOPS-20, et alia -- by diffs?
Date:
Message-ID: <87652unhns.fsf@Astalo.kon.iki.fi>
Bruce Stephens <············@cenderis.demon.co.uk> writes:
> The GNU project always threatened to add file multiple file versions
> to their system. Anyone know whether anything in Hurd actually does
> that?
Nothing did when I last checked a few years ago.
It supported the ISO 9660 file system though, which might
technically allow versions; but the implementation was read-only.
Note that there does exist a CVS-filesystem for FUSE (linux
userspace filesystems).
http://cvsfs.sourceforge.net/
David Golden
(who will post something lispy to c.l.l. at some stage,
honest...)
From: Christopher C. Stacy
Subject: Re: File versioning on TOPS-20, et alia -- by diffs?
Date:
Message-ID: <u652w1k8d.fsf@news.dtpq.com>
Peter Seibel <·····@javamonkey.com> writes:
> So back in the day when Real Operating Systems kept multiple versions
> of files did they do it the way today's version control systems do, by
> storing (reverse) deltas? Or did they just keep multiple copies around?
Just multiple copies of the file.
From: Christopher C. Stacy
Subject: Re: File versioning on TOPS-20, et alia -- by diffs?
Date:
Message-ID: <upt0me4kp.fsf@news.dtpq.com>
I re-read this thread and noticed that you didn't get an
authoritative complete answer. The supposition made by
Bruce Stephens and the answer from Bob Bechtel apply to
the other operating systems as well. Versioning was invented
on ITS; subsequently, TOPS-20, VMS, and Genera (LMFS) all worked
by creating an entire copy of the file for each version (which
was called a "file generation" on TOPS-20).
The purpose of these file "versions" was not quite the same as
"version control" systems like on CVS. Rather, it was to have an
automatic backup of the file you were editing, to protect against
mistakes. It provided complete checkpoints of the state of your
edits as you were working. Reverting or diffing against the version
from 5 minutes or two hours ago or yesterday is conceptually different
than committing ("checking in") a desired set of changes to a version
managed project tree.
A critial feature of versioning support is that it is transparent.
Versioning came for free, and of course, was not limited to the editor.
It's built into the file system, and all programs could take advantage
of them (the normal mode of operning a file for output would create a
version, but programs that really didn't want to make a new version
could prevent it). You normally open files without referring to the
version number at all (and you get the latest version). You only
have to mention a version if you want some other particular one.
There are also magic version number tokens meaning "oldest" and "newest".
(On ITS those were the ">" and "<" version numbers.)
Genera also had a source control system, but that was seperate from
the file versioning feature -- a specific version of a file could be
checked into the system, but other versions of the file had nothing
to with it. In other words, the version was just considered part of
the file name. Genera's version control system didn't get used much.
Genera also implemented file versioning on Unix (since you were only
going to OPEN the files through its interface). You could use it
selectively, so that for example only specific source code directories
would be versioned. This is sort of like what GNU Emacs does.