> On Sun, Jun 04, 2000 at 11:08:29AM -0400, Jonathan S. Shapiro wrote:
> > The SCCS storage format isn't terribly efficient. Actually, it's famous
for
> > having sucky performance.
>
> I am certain this is an artifact of the implementation.
Actually, it's the nature of the file format. RCS stores the most recent
version with deltas to get to old versions. SCCS stores the original and
requires that all deltas be re-applied on each checkout (and checkin, for
that matter). The SCCS file format is a bit cleaner, but after 100 deltas or
so it's a profound loose.
> Xdelta's big claim to fame was handling
> binary files efficiently, yes?
I think you may be confusing xdelta with vdelta, but in any case yes: xdelta
is more efficient.
> I remember being annoyed at some version of PRCS because
> the archives were always binary... In my opinion, if the data
> stored in the file is 7-bit ASCII, the entire archive file should
> be 7-bit ASCII.
We have a significant disagreement here. In my opinion, the archive file
format is the business of the archive, and it's none of the user's business
whether that format is binary, ascii, or morse code. My feeling is that the
right way to handle text files is to introduce the notion of
inbound/outbound filters. The inbound filter canonicalizes the newline
convention and (if appropriate) removes variable expansions. The outbound
filter expands variables and converts everything to client-normal form.
While the CM system must keep track of what filters are required for each
file, it has no need (and indeed no business) being able to manipulate those
files while in the repository itself.
A binary convention within the repository actually simplifies things, as the
server side of the repository system ceases to be conditioned on file type,
which has proven a useful simplifcation for my stuff.
shap
Received on Sat Oct 21 14:36:05 2006