[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 14:17:09 -0400

Quoting Jerry McAllister <jerrymc_at_msu.edu>:

> On Wed, Oct 29, 2008 at 01:15:34PM -0400, Robert P. J. Day wrote:
>> currently, i have a small group all working out of the
>> same repo that was inherited from elsewhere, which contains
>> a chaotic mixture of LF and CRLF end-of-line characters on
>> all of the *.c, *.h and Makefile files. what is the best
>> (and safest) way to do a massive normalization and change
>> everything to the UNIX native eof of LF, across the repo
>> and everyone's working copies?
>> i don't want to have to force everyone to stop editing,
>> save and check back in everything they're working on because
>> some of the work is still in progress, so we can assume that
>> *some* stuff in working copies will differ from the repo --
>> hopefully, not a lot, and not in an unmergeable way once the
>> eol change is taken into account.
>> first, in order to get everyone's sessions in sync, should
>> i get them to change their .subversion/config files to enable
>> auto-props, then uncomment the appropriate eol-style=native
>> lines? i checked and some of them don't have that set, so
>> i was assuming that would be step one.
>> and after that, what? i can have everyone "dos2unix" those
>> files in their working copies, then i can check in a dos2unix'ed
>> clean version, and have everyone try to update. is that the
>> right recipe? thanks.
> I presume that the ones with CR are from MessyDOS/Win environment
> and what they have is CR-LF at the end of their lines and that
> the others all have just LF at the end of lines (UNIX style) and
> that none have only CR as a line ender.

   that would be correct.

> In that case, just removing the CR would do the trick.
> You could use the dos2unix utility. It has been a very long
> time since I have used it, but I think it worked fine.
> Another one is to use tr(1) on the files. It could be used
> on every file across the board without confusing anything even
> if they didn't have any CR-s in them. Something like:
> tr -d '\r' <infile >outfile
> That tells it to read infile, delete all RETURNs and write to outfile.

   oh, i know how to fix the files *locally*. since all of my stuff
is checked in, i can trivially check out a fresh working copy, make
massive normalization changes, and check back in without a problem.
that part's easy.

   what i'm after is what prep work i need to do for the *others*
who all have working copies in which they're currently doing work,
so that when *they* try to update, they're not hit with a blizzard
of merge conflicts based on different EOLs.

   i've already told them to edit .subversion/config, and set up
an eol-style of LF. and they do use a mixture of tortoise, rapidsvn
and straight command line checkouts. so i'm trying to lock this
down so that, once we get all this normalized, it can't get out of
sync again based on people mixing their editor usage.


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 19:17:32 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.