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 --
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
Received on Sat Oct 21 14:36:52 2006