On Aug 11, 2015, at 12:49 PM, arnoldemu <[email protected]> wrote: > > I think the real problem is that I am used to a different merge program and I > can't get along with kdiff3.
As Richard says, you should let Fossil be your “merge program.” :) > It is true I am using Windows and Linux. I never had a problem with line > endings with fossil. It just works! Some VCSes are so dependent on line ending style that they basically break down if you don’t enforce a common style. (e.g. CVS) While it is true that Fossil’s binary diff algorithm will cope with constantly swapping line ending styles, that doesn’t mean there is no problem. All it means is that Fossil is perfectly willing to check a bunch of CR/LF diffs into the repo along with your substantive changes. The problem comes during merge, when a CR/LF style change means that every line in the file has changed, so that Fossil can’t safely merge automatically. I don’t know what Fossil’s rule for “safe” is, but Subversion’s is that two nearby changes have to be separated by at least 3 lines before it will auto-merge. Otherwise, it considers the changes potentially overlapping, and makes the human do the merge. When a file changes in line ending style, every line has a diff, which makes automatic merges impossible. > On perforce, at work, when I get latest it automatically converts line > endings, Someone asks for that feature every several months, but the request has always been rejected so far, since there are logical counterarguments against auto-conversion. This isn’t so much about Fossil as about general design principles: https://en.wikipedia.org/wiki/DWIM https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Autocorrection#Disadvantages Search the list archives if you want to read the arguments specific to Fossil. Me, I can go either way on the issue. Both sets of arguments are sensible, and both have disadvantages. It isn’t a choice between right and wrong, it’s a choice of which bag of problems you want. > I use scite to edit my code on Linux and Microsoft Developer Studio 2013 > (Community edition) on Windows. scite doesn't care about line endings. Some testing here with VS 2013 Professional says it will preserve existing line ending styles. The docs agree: https://msdn.microsoft.com/en-us/library/dd409797(v=vs.120).aspx Beware the warning on that page that the editor will preserve the line ending style of pasted text, potentially created mixed line endings. I have run into this in the past, which is one of several reasons I recommended running “fossil diff” before every checkin. Unless you actually need the compilers in Visual Studio, you might be better of switching from VS + SciTE to some cross-platform editor that preserves line endings. Microsoft recently came out with Visual Studio Code, which runs on OS X, Linux, and Windows: http://code.visualstudio.com/ There are other good cross-platform non-mangling programmer’s text editors: Vim, Sublime Text, Emacs... > "./arngui/arnguiApp.cpp contains CR/NL line endings. Use --no-warnings or the > "crnl-glob" > setting to disable this warning. > > Commit anyhow (a=all/c=convert/y/N)? > ". > > I answer "a" for all. You shouldn’t be ignoring this warning. It is warning you about a real problem, which may either be a one-off case (e.g. accidental mixed line endings) or a chronic one (e.g. line ending style inconsistent with Fossil settings.) You should either: 1. Decide that the project’s line ending style is CR+LF to cater to Visual Studio, then set the crnl-glob setting so that Fossil knows which files are text files, and thus don’t need this warning; or 2. Choose LF instead, and use text editors that don’t rewrite LF files as CR+LF, and which visually warn you about mixed line endings. (e.g. Vim, which shows colored “^M” characters when you have a file with mixed line endings.) > * What is the default/server line ending? Fossil comes out of the Unix world, so when in doubt, it assumes LF. But, beware that Fossil’s diff algorithm is a binary diff, not a line-by-line diff. That means it isn’t storing the whole line when LF changes to CR+LF or vice versa, it is only storing info needed to describe the addition/removal of the CR byte. > * What does convert do? Convert from native (e.g. \n on linux and \r\n on > windows) to... what line ending??? To LF, regardless of platform. See line 1551 in src/checkin.c. The crnl-glob setting suppresses this, saying that “any CR” is legal in files that match the glob pattern(s) in the setting. Beware that this means it will happily accept a file with mixed line ending styles, or classic Mac (CR-only) text files. This is a strong argument in favor of choosing option 2 above, by the way. :) _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
