On 7/3/06, Joe <dev@freedomcircle.net> wrote:
> Erik Huelsmann wrote:
> > * Subversion was intentionally designed not to modify files under
> > version control until explicitly told to do so. You may not think your
> > files changed when you want different line-endings, but others may:
> > say you checked in a subversion dump file. If the system started to
> > subsitute line endings for you, the file would have been damaged
> > beyond repair, even though it looked texty. The default is (and
> > *should stay*) to protect your data.
> >
> > Please don't project any problems you may have right this instant on
> > the version control system you're using: your problems are (largely)
> > unrelated to version control, but to inter-OS moving of files.
>
> Thanks Erik. I can see your point. However, it is a design decision of
> Subversion to use a heuristic for determining whether something is text
> or not. Compare that with FTP: if you transfer in "ASCII" mode it will
> modify a UNIX file and create it with CRLF on Windows, and vice versa,
> i.e., it uses an explicit mode rather than a heuristic.
If I understand you correctly, the above isn't true: Subversion - by
default - doesn't assign meaning to the contents of files being
committed: it doesn't distinguish between text or binary and it
doesn't do eol conversion. That way, the files don't get damaged. When
Subversion would do eol conversion by default, files would get
modified at checkin and there wouldn't be any way to reconstruct the
original. That's why we make it an explicit choice to have eol
conversion.
The only time Subversion uses a heuristic to estimate textiness is
with 'diff' related operations (blame, diff, merge), never with other
situations. BTW: there is no other way to determine whether Subversion
is looking at a text file but to use a heuristic: all files consist of
bytes, the meaning we assign to them is different on a case-by-case
basis (you can just name your JPG images photo.txt, they won't become
text files).
> Since most VCSs
> started being used for storing and controlling program source files, I
> was expecting a similar behavior.
Right. We learned from CVS in this respect: many a time people forgot
to use the 'this is a binary file, please don't modify'-option when
adding an image to the repository. Most of them were damaged,
sometimes not even recoverable (because the original was deleted).
> It still seems to me that forcing clients to deal with auto-props is not
> the best decision since it's too easy to miss a file suffix or have some
> newbie developer in a large mixed-platform group forget to set props and
> start submitting changes and screwing things up (yes, the peers will
> hopefully catch the problem before it gets too far, but IMHO the VCS
> should be preventing this).
Absolutely. This is one of Subversion's weak spots. You as a sysadmin
can prevent the file ending up in the repository by checking for the
right properties and rejecting the 'newbie commit' in a post-commit
hook.
> As I hinted before, I'd prefer a server-based capability that says: all
> our files are text files and we want to store them at the clients in
> native format and at the server as "collection of logical lines", except
> for files which we specify as binary at the client. This still would
> allow companies that have mostly binary files to specify otherwise
> (either at the server or the client).
Absolutely. We have had extensive discussion on the development list
about use cases and how the implementation behind this should work.
Especially also how changes in the configuration would propagate. In
the past discussions, we didn't reach a final conclusion of how it
should work though.
If you have resources to spare (time to discuss design or
implementation), you're most welcome to come to dev@ and stirr up the
discussion again. You can read about it all through the mailing list
archives at http://svn.haxx.se/dev/
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 3 09:54:53 2006