HEDRICK@RUTGERS.ARPA (08/04/84)
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA> There is always a problem with mixing two different systems. I use both Tops-20 and Unix. I like the way Tops-20 manages multiple versions. I also find Unix livable. However any simple attempt to import Tops-20 features into Unix is going to end up in something that is worse than both. You must certainly decide what to do about rename, delete, etc. It is possible to make this decision in a coherent way, as Tops-20 has done. However there are more implications to multiple versions: When you parse a file name, you must know what is going to be done with the file, since if you are creating a new one you will want a new version, while if you are reading a file, you will want the highest existing version, and if you are deleting it, you will probably want all versions. So Tops-20 has a set of conventions for filename parsing and the semantics of various operations. These conventions are implemented uniformly in all programs. (The COMND jsys and various packages based on this means that you don't actually have to write the logic yourself.) Doing all of this in Unix would require a serious piece of design, including the shell, the kernel, and many of the utilities. The problem of multiplying versions does have a solution. Most users has a generation retention count to 1. That is, all but the most recent version are deleted automatically. Because of the ability to undelete, this still gives you the ability to back up, but at logout (or explicit expunge), everything gets cleaned up. Generation retention counts without undelete would be stupid, since a generation retention count of 1 would be equivalent to have no versions at all. Multiple versions without generation retention counts would be wasteful of disk space. So you see that it is hard to take some of Tops-20 without taking it all. If you don't want to do this, I think there are simpler ways to handle the problems that versions solve, but within Unix. I think there are two major problems: - needing to keep around old versions of things because you want to be able to back out of changes, or to see what changes you have made - providing the ability to undo mistakes. I agree that the first can often be solved by explicitly renaming things to foo.OLD. Indeed even under Tops-20 we normally do that. Because of the way versions multiply, we have to remove all but the most recent version at the end of a debugging session. It is all too easy to go just one step too far and delete that old version you wanted to leave around, while you are deleting all the intermediate versions that the editor left automatically. Thus I normally rename the original version to something else. I think the only place where mechanical assistance is really justified in this is for source files. Binaries can usually be rebuilt if needed, and databases and other more complex things need more specialized backup procedures. Since EMACS already changes the original version to foo.BAK, I think this problem is more or less solved. My only complaint is that I would prefer to have foo.BAK made only if there isn't one already. EMACS currently makes it for each editing session (removing any old foo.BAK). As for the ability to undo mistakes, by far the most common case is where I do something and realize immediately that I typed the wrong command. If it would be possible to supply the ability to undo the most recent deleting or superceding command (which might include wildcards), I think that would be just what is needed. This will probably require kernel support. Having a new command that is a reversible "rm" is a nice interim solution. But one would also like to be able to undo the case where somebody says cc -o foo.c foo.c by mistake. Unfortunately I am not a sufficient Unix wizard to know whether this suggestion is practical. -------
gwyn@BRL-VLD.ARPA (08/05/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> cc -o foo.c foo.c will not clobber your source on UNIX System V. This trivial safety check (as well as others to keep "cat" from writing the file it is reading and so forth) could easily be added to older versions of UNIX. As to keeping backup copies of source code, that is what SCCS is for.
ssimpson@trwrba.UUCP (Scott W. Simpson) (08/05/84)
At our site, one of the wizards who has since left TRW
has written a program called delete which deletes files by prepending
their name with ".,". Consequently, when you do an ls, it appears
that the files are deleted. In the wee hours of the morning, all files
that begin with ., are deleted. This somewhat solves the reversible
rm problem.
Your assumptions about the C compiler are incorrect. When I tried
"cc -o test.c test.c", I got the error message "cc: -o would overwrite test.c".
--
Scott Simpson
TRW Electronics and Defense Sector
...{decvax,ucbvax,randvax,ucivax}!trwrb!{simpson,ssimpson}ron@BRL-TGR.ARPA (08/06/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> As a matter of fact all the versions of CC that I've ever used wouldn't allow -o on to something.c or something.s. F77 and the loader don't seem so cautious. Once again system V is nothing special. -Ron