On Sat, Mar 15, 2008 at 12:21:47AM +0100, jiho wrote:
I'm not sure there's really a need to continue counting points right now. It seems bazaar is the clear winner.
I've been composing the below before the above was posted.
Looking at http://en.wikipedia.org/wiki/Comparison_of_revision_control_software, there is one startling difference among git,hg,bzr: it is stated that bzr cannot do end-of-line conversions, i.e. cannot adapt the end of line characters for text files such that they match the end of line style for the operating system under which it is used. (Status: http://bazaar-vcs.org/LineEndings)
I wonder how much of an issue this is; could it actually be fatal for what is otherwise a very promising alternative? Let's look at how we would address this issue if we were to choose bzr.
If a commit includes a change that adds or removes CR to/from the end of each line, then it tends to make it awkward to merge changes for other people (at least in most systems, I suppose in bzr too). Thus, it would be nice if we could ensure that the "right" line endings are in use at commit time (converting or refusing to commit rather than committing the wrong thing) so that we never have commits that change the line endings in the repository version of the file. The checkeol plugin (http://bazaar.launchpad.net/~bialix/+junk/checkeol) promises to do this. How does one set it up -- can we make it enforce our chosen line ending convention for new files, or will it only check that existing files keep their existing line ending convention? If checkeol works well then we just need to decide what the "right" line ending is for each file type, and hope we never need to change our mind.
One issue is that, for traditional Unix tools, backslash-CR-LF means something quite different from backslash-LF. I've just tested: DOS line endings work fine for g++ and gnu make 3.81 (though I seem to recall that earlier versions didn't accept DOS line endings for backslash purposes), but not for shell script (either dash or bash).
It's been a while since I've used cygwin, but I believe that cygwin slightly prefers Unix line endings: that Unix line endings always work, while cygwin can be configured to allow DOS line endings.
So at least for shell scripts, we want Unix line endings.
I believe that all popular editors on both Un*x, MacOS and Windows will happily edit files regardless of their line-ending convention, preserving that convention for lines added; except that the ever-present Windows Notepad requires DOS line endings. (Notepad isn't a programming editor, it's just the default text file editor, and I've come across people editing source files with it.) My information is rather dated, though. (Does the default text editor in Windows still not play well with Unix line endings?) Can anyone name other popular editors that don't work well with non-native line endings? vi other than vim don't handle non-Unix line endings, though I don't know if any Inkscape developers would use vi other than vim; solaris users perhaps?
The main annoyance regardless of platform (depending on whether checkeol converts or merely warns) is when adding files, particularly when adding a large number of files. Tools like fromdos/todos will help, once installed. (Extra barrier for Inkscape development participation.)
Does anyone feel like advancing the state of this feature in bzr ?
Otherwise, what convention would we choose for text files other than shell scripts? READMEs I really don't care one way or another. C++ source code I hope we go with Unix [no doubt influenced by my being a Un*x user] but can see arguments for choosing DOS line endings.
pjrm.