Re: ghudson's 'svn st' problem he mentioned on IRC...

[Greg Hudson <gh...@MIT.EDU>]

On Wed, 2003-12-31 at 18:42, John Szakmeister wrote:
> 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 had initially advocated committing all files as-is, to avoid any
possibility of binary corruption, so that the repository representation
of text files might flop back and forth between LF and CRLF as commits
were done on Unix or Windows, but of course the client would make them
consistent.

That didn't take, but as a compromise, we refuse to perform
data-destroying translation on files with an svn:eol-style of "native".
We error out rather than convert a file with mixed line-endings.

But for the fixed eol-styles, we assume those are only going to be used
in very special cases, like MSVC project files, so the chances of them
being accidentally applied to a binary file are low.  Also, files like
that are more likely to get mixed newlines when edited on platforms
whose native newline style doesn't match the fixed style.  So, for those
newline styles, we do perform potentially data-destroying
transformations on commit.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ghudson's 'svn st' problem he mentioned on IRC...

[John Szakmeister <jo...@szakmeister.net>]

On Wednesday 31 December 2003 20:00, Greg Hudson wrote:
> On Wed, 2003-12-31 at 18:42, John Szakmeister wrote:
> > 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 had initially advocated committing all files as-is, to avoid any
> possibility of binary corruption, so that the repository representation
> of text files might flop back and forth between LF and CRLF as commits
> were done on Unix or Windows, but of course the client would make them
> consistent.

Ah, yes, I seem to remember this discussion a little.

> That didn't take, but as a compromise, we refuse to perform
> data-destroying translation on files with an svn:eol-style of "native".
> We error out rather than convert a file with mixed line-endings.

Good to know!

> But for the fixed eol-styles, we assume those are only going to be used
> in very special cases, like MSVC project files, so the chances of them
> being accidentally applied to a binary file are low.  Also, files like
> that are more likely to get mixed newlines when edited on platforms
> whose native newline style doesn't match the fixed style.  So, for those
> newline styles, we do perform potentially data-destroying
> transformations on commit.

Okay, that makes sense.  I was worried that we could do something a little 
strange that might result in the corruption of a binary file from the 
beginning, but it appears that you have to work awfully hard in order to 
actually do that. :-)

Thanks for the explanation Greg!

-John


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org