[PREVIEW] line-endings support

[Talden]

> > I agree that exposing this as a property in Subversion was a mistake -
> > it should be clear to users that setting it changes tool behaviour -
> > Properties in subversion look more like data than configuration and
> > that can be confusing.
> >
> > None of this should detract from the huge benefit this addition makes
> > for many users allowing more projects to move to Bazaar.

>  Guys, I never used svn heavily, so I'm not familiar with things you're
> talking.
>  And I don't understand why exposing 'eol' or 'bzr:eol' property to user
>  as regular versioned property is *bad* thing.

Properties in Subversion are sometimes used by users tools to drive
workflow or to annotate content to add information.

The 'eol' property proposed here is different - this special property
changes the behaviour of the version control tool to store content
that is potentially different to what the user committed.  This is an
important distinction as changing the value of the property can change
the value of file content.

I agree that
- EOL conversion shouldn't be applied by default (behaviour won't
change with upgrades unless requested).
- Flags controlling EOL conversion should be version controlled
(needed for history stability).
- The flags should be pattern based rather than stored with each
affected path (subversion got this wrong for EOL and mime-type at
least, user properties are another matter).

I don't agree that the EOL support should use properties exposed
alongside any other user properties.  This could be my Subversion
experience surfacing here - I just wouldn't want a 'proplist' of a
file/pattern to mix bzr-configuration properties with user content.

>  Versioned properties storage is general purpose storage. It's not
> differentiate
>  between various properties, according to my design document:
>  "VP does not provide any particular meaning for key/value pairs.
>  Clients may assert a meaning for themselves". bzrlib is also client
>  of versioned properties here.
>
>  Currently for working with VP there is 3 basic commands:
>  prop-set, prop-get and prop-del (to set/get/del).
>
>  Now you say that to set 'eol' property there should be separate command.

No. I'm saying that 'eol' shouldn't be a visible property (it could
still be implemented that way) and a separate command provided to
interrogate and modify eol settings.

>  But if I wanna to see this property I need separate get command, of course.
> Yes?
>  And separate del command too?

That depends upon the design of the UI.

EG. Remove the current EOL conversion rule for *.txt (if one exists)

    $ bzr eols --remove *.txt

EG. Set or alter the EOL conversion rule for *.sh

    $ bzr eols --add *.sh LF

EG. List the EOL conversion rule for *.java

    $ bzr eols *.java
    *.java     NATIVE

EG. List all of the current EOL conversion rules

    $ bzr eols
    *.java     NATIVE
    *.sh       LF

EG. List the EOL conversion rule changes for *.java in revisions 2..4

    $ bzr eols *.java -r 2..4
    revno: 1
    *.java     CRLF

    revno: 4
    *.java     NATIVE

These are merely examples, you might want some log-format control to
understand changes to the EOL conversion rules.

>  Today I finish support eol properties. Tomorrow I or different person will
> start
>  writing support for binary files properties. Or something other on top of
> versioned
>  properties. And we again need to provide separate set of commands for this?
>  Do you really think it's good to add new commands every time? I think not.

For functional changes to bzr behaviour.  Yes I do.  adding support
for a general version property facility is a good thing and this looks
to have been achieved - I'm just not convinced that a single
command-set should provide for 'user properties' as well as 'bzr
behaviour configuration'.

This is not a challenge to the value of the VP feature, only a
challenge to the appropriateness of using it (as a UI) for EOL
conversion.

--
Talden