[PREVIEW] line-endings support

[Alexander Belchenko]

Talden пишет:
>>  > Used simple file properties implementation does not require format upgrade
>>  > and eol support will work with any working tree format (WT2, 3 and 4).
>>
>>  > To start using eol support you need set 'eol' property for some files
>>  > or file mask, e.g.:
>>
>>  > $ bzr prop-set *.txt eol native
>>  > $ bzr prop-set *.py eol LF
>>  > $ bzr prop-set binary.file eol exact
>>
>>  File properties should imho be an implementation detail rather than
>>  something that's exposed to the user. I think this is one of the
>>  things that Subversion got wrong. It's fine for a "bzr prop-set"
>>  command to exist, but it should be there for debugging purposes rather
>>  than as the UI you use on a daily basis.
> 
> IMHO some things shouldn't be exposed as properties - they should have
> their own command-space.  This is especially true of something like
> the EOL handling since it drives functionality that mutates committed
> and checked out content.  Of course custom properties are used in
> Subversion as well and supporting that is a good thing for those that
> use them.
> 
>>  Instead, I'd like to see us have a separate command for changing the
>>  line ending policy on files, e.g.
>>
>>  $ bzr eol-style "*.txt" native
>>  $ bzr eol-style "binary.file exact
>>  $ bzr eol-style "*.txt"
>>  native
> 
> Even if this were implemented as properties, I would expect all
> properties under a special namespace (EG 'bzr:') would be hidden from
> prop-get, prop-set commands - each would, I expect, have it's own set
> of CRUD commands.

What is CRUD?

> 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.

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.
But if I wanna to see this property I need separate get command, of course. Yes?
And separate del command too?

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.

I think better to write detailed and clean user documentation on supported versioned
properties and carefully describe how some properties affects bzr behavior.

I want to pick only suggestion about 'bzr:' prefix for property name.
I think it will be reasonable policy to treat all properties with 'bzr:'
prefix as those who affected behavior of bzr itself. I.e.

'bzr:eol' instead of 'eol' to clarify intention of this property: provide
support for eol at bzr level. IMO, it's good idea.