"file type" support Justin Mason (jm@jmason.org)
Wed, 12 Apr 2000 12:27:18 +0100

Bill Frantz said:

> Unfortunately, for source files we must fact up to the line end issue. (I
> deeply wish one system had won. Even the one I most dislike.) My
> suggestion is to define a canonical line ending convention,
and convert all
> incoming source files to that convention.
> There may be a need to support binary files as well. An example
might be
> project files for some of the popular IDEs.

Definitely! Also images, etc.

Note that some projects may require so-called "text" files, but with the line-endings preserved; so being able to specify a file as being of type text or binary would be beneficial, without any CMS file-identification heuristics getting in the way. Being able to re-designate an existing file as being a different type would be good too, but I suppose a delete op following by an add -t type op would be acceptable.

There will probably be more required types of course, as this discussion goes on. I can think of one other useful one, used by Perforce to support RCS-style $Id$ tags; Perforce uses a default file-format type of "text" which will not interpolate these tags, and is faster as a result; then "ktext", which will, and is obviously slightly slower.

It also uses a file type to represent if the file should be executable or not (which IMHO sounds like a workaround requiring another layer of metadata in their system ;), and a file type for a symlink (first time I've seen a CMS that allows check-ins of symbolic links!). Also, it has 2 file types for binary files, one of which is stored compressed in the repository, the other uncompressed (for already-compressed binaries), which is a nice tweak.

Their binary format does not handle deltas. The entire binary file for each rev is stored in the repository.

BTW, on another issue: regarding encryption of repository files -- would it be possible to simply allow optional encryption of the on-disk representation? Then, if the synchronize/commit/label operations, and other ops that require network traffic, are able to be used over an ssh tunnel, you've got a reasonably secure system without too much work being involved, and you won't have crypto throughout the code, just in the file IO code.

BBTW being able to run the network aspects over an ssh tunnel will greatly simplify the usability of it too IMHO.