On Tue, 2001-12-11 at 18:56, Bruce Atherton wrote:
> As I read the document, the copy of the file that is initially checked in
> to the repository will never have any changes whatsoever. When the file is
> checked out the line endings could potentially be changed, and after
> editing a precommit alteration may occur but only if the endings changed on
> checkout.
(I hate our mail archiver. It takes so much effort just to look at the
most recent few messages to the list.) Ben's document says:
- 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.
Nor is the initial commit the only one which might contain data we don't
want to destroy. For example, on a vendor branch (or vendor directory,
since we don't really have branches), every commit is going to be the
result of copying in a file from an outside source. Or some kind of
binary editor might be involved. 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.
---------------------------------------------------------------------
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