On Wednesday 31 December 2003 13:12, email@example.com wrote:
> > To be honest, the fact that the repository changes kind of frightened
> > me, so I tried a few things from the command line.
> It shouldn't be frightenening -- we simply decided that a fixed eol
> style should be stored in the repository using that eol style. In
> other words, as far as eol style goes, the file should be treated like
> a binary, since we're not going to do any client-side translation on
> it. Changing to a new, fixed eol style and committing is like
> committing any other kind of text change.
The reason was frightening was the Subversion is more binary friendly, and if
for some reason a binary file is added to the repository with the eol-style
got applied, then we'd have a corrupt binary file in the repository.
> > I tried to get a
> > file into an inconsistent state by making it binary, attempting to set
> > the eol-style, and then making it text. I was very happy to find that
> > I couldn't do it (the tool would not let me add the eol-style property
> > to the file).
> When you say "making it binary", do you mean setting the mime-type?
Yeah, that's what I meant. :-) I set it to application/octet-stream to be
> > So, in the end, I think you're right. :-) The COM bindings have been
> > around in their state for long enough that they just happened to
> > remain unchanged throughout all the line ending changes that were made
> > to the tool. We should probably touch the files and just commit them
> > so the contents of the repository get updated correctly, but I'll
> > leave that task to someone else.
> Yup. Thanks for all this research!
> You obtained a list of all such files recently; can you post it, and
> I'll fix them?
Hmm, don't know if I got a list of them, but I know what they are:
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jan 1 00:43:41 2004