[PREVIEW] line-endings support

[Ian Clatworthy]

John Arbash Meinel wrote:

> So... my opinions on the good and bad of something like this.

> If I change the '.bzrprop' file, and then do a:
> 
> bzr commit -m "just foo" foo
> 
> How should 'foo' be handled. I think it should technically use the
> '.bzrprop'
> that has already been committed, ignoring the one in the working tree. Why?
> Because when you check it out, that is the one that is going to be read.

Good point.

> Having the file somewhere else makes it clear that you just use that file.
> 
> Having versioned properties associates the data with the file you are
> committing. So it isn't possible to commit the data without the
> meta-data. (Now,
> you can get creative with a .bzrprop file and commit the portions of the
> file
> that relate to what you are changing, but that gets *really* tricky.)
> 
> Note that I think the way to solve this is to introduce a
> SelectedFilesWorkingTree object, which can grab the contents of files
> based on
> whether they were

Can you complete your thoughts here?

> 4) Merge conflicts
> 
> If the .bzrprop file conflicts at merge time, how do you finish checking
> out the
> working tree? Because you may have conflicting info for the files that
> need to
> be modified.

Another good point.

> 5) Recursive properties
> 
> One thing I really *don't* like about Subversion is that "svn:ignore" is
> not a
> recursive property. Which means that every time I create a new Visual
> Studio
> project, it tries to add all of the executable files and .obj files. And
> there
> isn't a good way around it.

> I think our .bzrignore is much better than svn:ignore, it would be nice
> to do
> similarly well with our line-ending support.

Agreed. Having said that, there is an argument (as you know) for not
putting control files in the tree. In the case of .bzrignore,
http://bazaar-vcs.org/NewIgnoreRulesSpec has some suggestions on how we
could store ignore rules in another way and migrate to that other way.

> 6) Patterns versus explicit file-id

> That's all I have for now, but it might give Ian some more context about
> line-ending support.

Yes, very helpful thank-you.

In summary, I see 3 main options for configuring eol support:

1. A small number of global settings like Hg:
   http://www.selenic.com/mercurial/wiki/index.cgi/Win32Extension

2. Patterns like Git:
   http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

3. File version properties like Subversion.

My gut feel is that:

* (1) has it's limits but might be enough for a first cut.
* (3) will have some scalability challenges.
* (2) is pretty damn powerful, though potentially complex to
  debug.

Alexander's approach provides a combination of 2 and 3, and like Git's
approach, might be useful for numerous related features including
keyword expansion, per file diff and merge algorithms?

Thinking out loud, could we start with (1) and expand the solution to be
a combination of (1) and (2), where (1) would take precedence over (2)?
That would decouple (initial) eol support from the (long) debate over
if/how/when Bazaar should support generic attributes/properties.

Ian C.