Ben Collins-Sussman wrote:
>OK, after a lot of mulling and scribbling, I finally *get* Greg's
>proposed EOL-translation system. And I have to admit, I really like
>it.
>
>Here's my retyping of it -- I did this not because Greg gave a bad
>description, but because it helps me internalize the ideas. Greg, may
>have made a tiny tweak here or there. Let me know if my tweaks are
>odd.
>
> -- Greg's EOL translation system --
>
FWIW, I'm totally sold on this now.
+1
>Assume the EOL-style property means "desired style of file in the
>working copy". (The former meaning was "style of file in the
>repository.") If this property is not present, then the application
>assumes that the file's desired EOL-style is whatever is 'native' to
>the application's OS.
>
>Also, we continue to assume that EOL translation only happens on
>text-files, and that it's "on" by default, although toggleable.
>
>The text-base still reflects exactly what is in the repository.
>
>1. When the user commits a file, the *exact* contents of the working
> file is sent to the repository. (Yes, this means a lot of EOL
> flip-flopping in the repository, and larger-than-necessary binary
> diffs both over the wire and in the repo. But also means that
> data can never be corrupted, ever.)
>
>2. When user checks out a file, a 'translated' copy of text-base is
> provided as the working file. (Note: the working copy doesn't
> know what style text-base has; instead, it just always attempts to
> convert text-base to the file's desired EOL-style. This
> translation might often be a no-op.)
>
>3. When the user updates a file and a local merge is necessary,
> here's what happens. The new text-base arrives in .svn/tmp/.
> Then both the old and new text-bases are briefly copied &
> translated into the desired EOL-style, and a context diff is
> produced. (Either or both translations might be no-ops.) The
> copies are then tossed, and the context diff is applied to the
> working file. The new text-base replaces the old text-base. This
> is only very slightly more complex than our current system, which
> compares old and new text-bases directly to get context diff.
>
>4. The same logic as in #3 applies to any situation where we ever
> want to examine the text-base:
>
> - To see if the user made a local mod, we compare a *translated*
> copy of text-base with the working file. (This is only after
> the timestamp-comparsion shortcut fails, of course.)
>
> - To compare two arbitrary revisions of a file, we must always
> compare translated copies of them.
>
>
>I like this system, for the reason Greg pointed out: namely, it's
>majorly bad juju to store something *different* in the repository than
>what the user thinks was stored.
>
>This scenario has bugged us before: in the past, people have suggested
>ideas like "hey, why doesn't the repository reformat all code before
>storing it?" That idea has sent us all fleeing in horror. But now we
>face the risk of doing the same thing on the client-side... flee!
>Flee!
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
Brane �ibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
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:52 2006