On Fri, 2004-01-16 at 14:03, Erik Hatcher wrote: > Update of /cvsroot/xdoclet/xdoclet/config/.Refactory > In directory sc8-pr-cvs1:/tmp/cvs-serv8979 > > Modified Files: > pretty.settings > Log Message: > Hopefully this will fix Gump and not break anything else :) > > Index: pretty.settings > =================================================================== > RCS file: /cvsroot/xdoclet/xdoclet/config/.Refactory/pretty.settings,v > retrieving revision 1.10 > retrieving revision 1.11 > diff -C2 -r1.10 -r1.11 > *** pretty.settings 28 May 2002 22:13:50 -0000 1.10 > --- pretty.settings 16 Jan 2004 14:03:27 -0000 1.11 > *************** > *** 94,98 **** > # * NL - newline > # * CRNL - carriage return and newline > ! end.line=NL > > # This features sprecifies how to space out a field or a local > --- 94,98 ---- > # * NL - newline > # * CRNL - carriage return and newline > ! end.line=CR
Aha! That explains why files I've edited keep showing up as a single line when I do a CVS diff... It may have fixed GUMP, but it breaks things for anyone using Linux. I have to keep remembering to translate all CRs back to LFs before committing anything, otherwise we end up with stuff like http://cvs.sourceforge.net/viewcvs.py/xdoclet/xdoclet/modules/xdoclet/src/xdoclet/modules/doc/info/InfoSubTask.java?r1=1.11&r2=1.12 in CVS! There was only a single line that had changed in that one, not the whole file :-( Why should the pretty settings affect GUMP anyway, though? I thought the prettyprinter took CVS status into account, and only processed locally modified files? Andrew. ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
