At 08:06 PM 12/11/01 -0500, Greg Hudson wrote:
> - When committing, if working file's style doesn't match the
> file's official line-ending-style, then a converted copy will be
> sent to the repository.
>
>Presumably that applies to the initial commit as well as later commits.
But on an initial commit, there is no official line-ending-style for the
file, is there? I read this as "the first commit determines
line-ending-style" because the repository has no 'preferred' format.
>Consider the following case:
>
>1. I create some kind of vector graphic file, with no contents, save it,
>and commit it as a placeholder. Subversion's heuristic incorrectly
>identifies the file as text, but newline translation does not damage it
>because there is nothing in the file yet which looks like a newline
>needing translation.
>
>2. Later, I edit the file with my vector graphic editor, actually
>creating some complicated engine design or whatever. I check in the
>edited file; again, Subverion's heuristic incorrectly identifies the
>file as text, and this time newline translation destroys information in
>the document.
>
>In my scheme, I can recover the engine design by checking out the later
>rev of the file with an override option. In Ben's scheme, I am totally
>screwed.
Again, I'm not convinced although it may be my misunderstanding of Ben's
proposal.
Step 1. You commit the file with no contents. Probably not the most common
occurrence, but it is your story so you get to make it up and yes, it will
happen. Probably the best design would be to say that if there are no line
feeds in the file, it's "official line-ending-style" is "none", so no
conversion will ever happen to this file until that property is changed
manually. End of problem.
But that makes our story too short, and since this is an edge case that is
way too specific for Ben to have covered, I'll just make up some alternate
design here. Let's say that due to the lack of linefeeds in the file, there
is no line-ending-style setting at all. Yet.
Step 2. You check out the file. It goes into both the working copy and the
text-base. Because the official line ending is still an open question it
does not get any conversion on checkout and the text-base copy is identical
to the working copy. This means that when it is eventually committed again,
it will not get converted this time either. You edit the file and it ends
up with a few line feeds which are correct for your platform (any other
type would again get the line-ending-style set to "none" or the specific
style found) and it is checked in exactly as in the working copy, but with
the line-ending-style now set to "native".
Step 3. Everything is perfect until we checkout on another platform. This
causes conversions that munge our file because we didn't set the
line-ending-style properly. Perhaps you don't notice the corruption and
continue to edit the binary before committing again. The manner in which
the file is corrupted on a commit differs between your system and Ben's,
but in both instances it is corrupted. With your system, the checkout
conversions are never backed out. Of course, this being binary the line
endings may or may not have survived the edit but in any case the file is
likely not what it should be, and is possibly corrupted in subtle ways that
you won't pick up for a while. In Ben's system, the original line
conversions are backed out if they are still there, but new ones are
introduced.
No matter which system you use, Ben's or yours, the file is still
corrupted. The only advantage I can see to yours is that you may have seen
and accepted (perhaps even fixed) the corruption. This seems like a small
benefit to me.
---------------------------------------------------------------------
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