[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Newlines, preserving data, and multiple access paths

From: Bruce Atherton <bruce_at_callenish.com>
Date: 2001-12-14 19:55:55 CET

At 11:36 AM 12/14/2001 -0600, Ben Collins-Sussman wrote:
>Bruce's system seems a tad more complicated to implement, since it
>seems to require some kind of auto-detection of EOL style when a
>text-base is first received from the server.

As I mentioned in part two of my proposal, you could choose to store a
second property on a file that indicated what line ending it has in the
repository, but that would still be a property that only the client would
use. It isn't required, but it may be more efficient.

> And it also needs to
>'remember' that a transform happened previously; either that, or
>re-run the detection heuristic on text-base each time the working file
>is committed.

I was thinking of "remember", perhaps in the entries file? Except that
integrates it a little more into the client than may be desirable. In the
abstract, I was thinking more like a set of transforms (line endings,
keywords, whatever) that could be plugged in to a client or not depending
on user preference, and that would provide perhaps three callbacks
(transform_stream, reverse_transform_stream, requires_transform). In the
concrete, of course, that probably all goes out the window.

>Please correct me if I'm wrong. My brain is spinning, and I'm so
>tired of reading/thinking about this issue.

Me too. I'd given up on posting anything more on the topic, but thought
these clarifications might be helpful.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:53 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.