On Sat, Mar 15, 2008 at 05:15:33PM -0400, MenTaLguY wrote:
As far as I know, it's [...] not a feature we've been using in Subversion.
We have indeed been using it in subversion. Though we haven't had it set up to be added to new files automatically, so for example I see that the newly-added src/bind subtree doesn't use the feature. In the past, I've occasionally manually enabled the feature on new files (r1623{5,6,7}, r16085, r16043, r11156, r11011 according to svn log).
I've never seen this sort of feature work out well in practice. Invariably, binary files get marked as text or vice-versa. I've seen way too many problems over the years with files getting erroneously marked as "binary" or "text" when they weren't.
I have a feeling that svn handles it better than CVS, though I don't recall what the difference is. Maybe svn is better at guessing which files are binary. The absence of default keyword substitution can't hurt.
In most cases, problems can be fixed after the fact just by changing how the file is marked.
I agree that differing line-ending conventions are a source of pain, but I'm not sure that witholding conversion is the best way of avoiding pain: that option tends to leave inkscape with some files using CR-LF and some files using LF, and revisions that include changing the line-ending format of existing lines (which makes merging a pain).
Thus, if we are to choose bzr, then I believe we want to decide what line-ending convention to use for each type of text file, and use an automated commit-time check to enforce that convention.
Or we work on bzr to support an equivalent of svn's svn:eol-style property. Or we choose a DVCS other than bzr.
pjrm.