Hi Ryan,
Ryan Schmidt wrote:
> You seem to be under the impression that the presence of CRs in the
> dumpfile would prevent it from loading on a Subversion server running on
> BSD. But that should not be the case; there should be no problem loading
> the dumpfile, on BSD or any other OS.
I'm not sure why you think that because I've mentioned that I *did*
reload the dump file on BSD and everything was fine, except for the EOLs
on checkout.
> I don't think that's a good idea. Your repository is supposed to
> represent historical data, and you're proposing to rewrite history.
"Rewriting history" is where we disagree. I think of it this way. A
developer creates a source file on Windows. It's mostly transparent to
him that each line in the file has a CR-LF. He checks the file into a
version control system and when he checks it out, naturally, he don't
see any differences. However, with an auto-prop of eol-style native set
in his config file, underneath the covers, the VCS has mapped each CR-LF
to an LF on the check-in and vice versa on the check out. Another
developer (or the same one) creates another source file (perhaps a .h
instead of .c and he doesn't have auto-prop for .h). Check-in,
check-out, everything appears to work the same (but the VCS is now
storing the .h with CR-LFs).
Now the repository is moved to UNIX. The administrator does a dump on
Windows and a load on UNIX and everything looks good. Then the
developer does a check out of both files from UNIX. The first file is
fine, but when he opens the second file in an editor there's all these
ugly ^M's at the end of each line. To the developer, that doesn't look
right: he didn't change his source file! Yes, he forgot to set
auto-prop for the second file (or he didn't know about auto-props or
whatever), but as an administrator I don't think I'd be "rewriting
history" if I tried to mask the effects of the migration (and the lack
of foresight and/or knowledge about auto-props) from the developer.
> What
> if something breaks because of this change? What if you've inadvertently
> programmed in a dependency on DOS linefeeds at some point in your
> application, and your app now breaks due to this conversion? You
> wouldn't be able to go back in the repository to the last version where
> you know it worked to compare the changes. All your old versions would
> be broken too.
I'm sorry but I have trouble imagining how could I program such a
dependency in the source files. If I do code that, say in C, I'd use
literal strings like "\r\n" in the statements. Any "conversion" that I
would be looking for, would leave those literals untouched and would
only strip the CRs from the end of lines.
> I don't see why this problem is any more acute for Windows users vs.
> users of any other OS.
If you're on UNIX, a text file is stored with LFs on your local copy
*and* in the repository. If you're on Windows it's stored with CR-LF's
on your local copy and depending on how you set your auto-props it may
end up as is or with LFs in the repository.
> As you know, auto-props are described in the book. Was there some part
> of that section that was unclear? Or do you feel it should have been
> mentioned earlier in the book? Version control is a complicated topic,
> which is why there's a big book describing it, and not everything can be
> taught at once. You really have to start with the basics and then
> introduce additional concepts as you go along. Auto-props is not central
> to the function of what Subversion does, which is probably why it's not
> mentioned in chapter 1. But if you have suggestions for how the book can
> be improved, I believe they have their own mailing list.
No, it's not unclear and I agree that it's not something that needs to
be mentioned up front. However, just like there's an appendix for CVS
users, perhaps there needs to be a section of gotchas for users that
share repositories across platforms or that have the potential of
migrating from one platform to another.
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 16:44:18 2006