Ryan Schmidt wrote:
> Here's again where I'm getting that impression. Because you again
> mention a repository migration from Windows to Unix, and it sounds like
> you're implying that this migration would be the cause of the problems
> you're describing. But that can't be the case. A Subversion repository
> is a Subversion repository is a Subversion repository and behaves
> identically regardless of whether the server runs on Mac OS X, Unix,
> Linux, FreeBSD, Sun OS, Windows, pocket lint or good intentions. In the
> context of the svn:eol-style property, the component that behaves
> differently on different platforms is the client, not the server.
I'm sorry if I sound adversarial (:-) but you sound like you're saying
"Oh, it's not my problem if your Windows developers don't know about
auto-props and the files are stored with CRLFs and then they can't be
migrated easily to UNIX". That's like a database administrator telling
me "Oh, it's not my problem if your users (or your application
developers) don't know about encodings and now data that was entered in
Asia appears to be corrupted when retrieved from Europe".
My simple point is this: conceptually, the source files did not change
due to the repository migration; whether it's a client or server problem
is irrelevant to the users/developers. Subversion is not just a server
or just a client, but both.
If (about a year and a half ago) we had had foresight and/or had
understood correctly how auto-props would affect a possible migration
(or sharing the repository from another platform--neither of which we
envisioned at the time), we would've set up our config files
accordingly. What's done is done and all we can do now is correct the
situation.
However, I still believe that by implementing a different default policy
(whether at the client or the server), Subversion could prevent what
happened to us from happening to others. Granted, perhaps I'm presuming
too much and there are not too many who've tripped up or will encounter
this problem in the future.
BTW, the proposed default policy is that if a file appears to be a text
file, then the auto-prop svn:eol-style native *should* (in essence) be
the default (most likely a determination to be done at the svn client).
The main reason I think it's a better default is that in this way,
most text files will be stored in the repository as "logical"
representations (an alternative would be to store each line with a count
of characters and no indication of line terminators). I'll be glad to
argue this in the hackers list if desired.
> Well, you've got it exactly. In the source code of the script, I might
> be looking for the literal "\r\n" within a file, let's say foo.dat. What
> if foo.dat is also a checked-in file? If Subversion does some automatic
> line ending transformation as you suggest, and I now check out foo.dat
> on Unix, the file does not contain DOS linefeeds anymore, and the
> script, which is looking for DOS linefeeds in it, fails.
I'm sorry again but I think that's an unrealistic scenario.
> So there's no particular disadvantage to Windows users here. If you
> check in a file with one kind of line ending, without setting
> svn:eol-style, and then check it out to an environment where another
> line ending style is needed, then you've got a problem.
All of your examples tend to add to my suggestion that a better default
is to store text files as "logical" collections of lines, it doesn't
matter whether the server uses CRLFs, LFs, NULs or character counts.
For sharing across platforms as well as migrating between platforms, an
EOL-neutral representation is best, IMHO of course :-) With the
proposed default policy, if I check out a file and it doesn't look like
it has the correct EOLs, it's then easy to check auto-props or the file
properties to determine what's up.
> For this reason, we never use svn:eol-style=native. We standardize on
> all text files having Unix linefeeds, even when used it on Windows. Our
> Windows text editor can handle this, so this is not a problem. (Editing
> DOS text files with vi on Unix is a bit of a problem, with ^M appearing
> at the end of each line as you said, which is why we didn't standardize
> on DOS line endings.)
From my perspective, you've devised your own workaround (for what I see
as the deficiencies of svn:eol-style) by forcing a standard on your
developers.
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 29 23:06:58 2006