[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: doing a massive EOL normalization for a small group of users?

From: Robert P. J. Day <rpjday_at_crashcourse.ca>
Date: Wed, 29 Oct 2008 16:30:08 -0400

   a couple more mind-meltingly simple questions on all this EOL
normalization, and then i'll shut up.

   first, a question about the per-file eol-style property. let's
imagine i have a file that is currently checked in with proper
LF eols, and that there is no svn:eol-style property on that file
and no commit hooks to handle eol processing.

   in that case, i can check out the file (it will end up in my
working copy with proper LF eols), at which point i can mangle
the eols with "unix2dos". after i do that, i can use hexdump
to see the result, "file" will tell me there are CRLF terminators,
and "svn diff" will show me the massive file-wide difference and,
since there's no prevention, i can check it in with the CRLF
changes, correct?

   on the other hand, let's imagine that, after i originally checked
it out, i set its eol-style property to LF. after i do that, i
can still mangle its eols with "unix2dos" but, even after i do
that, "svn diff" won't now show me the differences, and "svn ci"
won't see anything to check in, and "svn up" doesn't seem to
update that file back to its original LF eol format. why is that?
do all of those client-side svn commands take the eol-style property
into account and ignore exactly those differences? it's not like
that would surprise me, i just want to confirm that that's what's
happening. (heck, even "svn revert" won't revert it back since,
i'm guessing, it also realizes it's redundant. i literally have
to delete the file and check it out again from the repo to get
the LF version back.)

   so far, so good?

   and it occurs to me that there might be an easier way to do
this. if someone's working copy has various changes sprinkled around
and has a mixture of LFs and CRLFs, i can have them record their
diffs with "svn diff" and save that output somewhere, then blow
away their working copy and check out a cleaned version. at that
point, they can just apply the saved diff back to their working
copy, but only after they "dos2unix" that patch file so that it
doesn't cause all sorts of problems. does that sound reasonable?

rday

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-10-29 21:30:34 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.