On Thu, 2001-12-13 at 15:57, Greg Stein wrote:
> The commit email scripts are running on the server only. It would be
> comparing two repository versions. Thus, you get huge diffs.
They work against the FS? That's an issue we'd have to address, then.
(It will be a similar issue for keywords, unless we decide to
de-substitute keywords on commit, which is considerably more destructive
than performing newline translation on commit.)
> Note that it isn't specifically related to DAV, but to *multiple access*
> paths. Any tool that operates against the repository is going to see large
> variances between revisions. For example: a commit email script. I envision
> a large variety of tools using scripting language bindings against the FS to
> do "interesting" things. The flip flop ripples out to them.
I'd be concerned that these same tools could have problems with files
using CRLF in the repository, if they are doing anything more
interesting than diffs between two revisions of the same file. "sed"
not finding text at the end of a line, stuff like that.
Here is a survey of how various schemes stumble over the multiple access
path problem. For the sake of argument, let's assume that all tools are
unforgiving about line endings, since the forgiving ones aren't an
issue.
* Ben's scheme: enforces LF for text files in the repository contents
(in the usual case). Tools using direct fs or DAV access work well if
they're Unix tools, but not if they are Windows tools. (We could, of
course, modify Ben's scheme to allow the repository to configure what
line ending style should be enforced for checkins, but that only works
if all the fs/DAV tools run on one platform and which platform it is
never changes.)
* Bruce's scheme: first commmit determines repository line ending style
(in the usual case). Tools using direct fs or DAV access work well if
they happen to operate on files which match their line ending style in
the first commit; they fail otherwise.
* Greg's scheme: repository line ending style varies for each commit.
Tools using direct fs or DAV access fail whenever they hit a revision
checked in with a different line ending style. Worse, tools which diff
between different revisions of the same file (using the FS contents)
produce ugly diffs.
* A new scheme which handles newline translation in the FS: works great,
but significantly complicates the FS interface and implementation.
---------------------------------------------------------------------
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