Bill Frantz said:
> Unfortunately, for source files we must fact up to the line end issue. (I
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
> 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.
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.
--j.