[MERGE] line-endings support: part 1 of 2: versioned properties

[Ian Clatworthy]

Alexander Belchenko wrote:
> OK, this finally happens.

Alexander,

Thank-you so much for working on this. Speaking with Martin and Robert
this morning, I have agreement to make it a priority of mine to work
with you on landing eol support. Hooray!

> This is ground part of my line-endings support work. This patch
> introduce versioned properties in bzrlib.
> 
> There was a lot of discussions and flames in bzr ML about line-endings
> and every time discussion
> went nowhere because in my understanding without any support for file
> properties we can't
> implement support for line-endings. So my primary goal is eol, and not
> versioned properties per se.

Now that I'm back from holidays, I've been reading over the numerous
email threads, digesting the various perspectives and opinions. As the
title of this message indicates, there are multiple parts to this puzzle
including:

* the mechanism used for storing the metadata
* the core logic
* the UI.

Each piece has multiple alternatives and each one of those has a
different impact on performance, robustness,  upgrades, usability,
merging, etc.

As I understand it, the most contentious bit is the storage layer. FWIW,
Hg's eol support doesn't use VPs while svn's does => there's more than
one way to do it. The design that Robert, Aaron and others discussed in
London didn't require Versioned Properties while numerous emails since
have implicitly assumed eol support would be built on such a layer. It's
not hard to see why - the notes on line ending support from the London
sprint were pretty terse.

So all of that suggests two things to me:

1. The guidelines for data management in Bazaar need to be more clearly
   articulated, communicated and debated. When is using a new format
   vs using configuration settings vs adding specific files (like
  .bzrignore) to the user's tree vs revision properties vs ... the
   right choice? We have gaps but are they just in documentation or
   also in features? Do we need more open extension mechanisms like
   versioned properties or nested configuration sections or ...?

2. Your code for eol support should be abstracted via a logical API from
   the storage mechanism. Getting "part 2" of eol support delivered
   on top of that is something we can do in parallel to the discussion
   on versioned properties. We *might* want VPs for a host of reasons
   and applications but we shouldn't block eol support on getting
   VPs landed first.

I'll grab a copy of your code so I can provide more concrete suggestions
about what I think the API should look like, etc. We ought to be able to
put together some code which delivers super-simple eol support by
reading just a few settings from bazaar.conf, say. E.g.

  eol_native = *.txt *.c *.h
  eol_LFCR = *.bat

The final implementation will undoubtedly be more complex but that ought
to be enough to validate that the API is indeed logical and that the
code above it works.

I'll also start putting together a "Data Management Guide" that captures
the currently available data management options, their pros and cons,
when to use each, etc. I think that will be really valuable for many
people looking to integrate with Bazaar, write plugins and extend the
core. Over and above getting eol support landed, I have several features
in my pipeline (e.g. filtered views) that need to manage extra metadata,
so I'm just as keen as you are to get this whole area clarified.

Sound ok?

Ian C.