[MERGE/RFC] Versioned properties spec

[Alexander Belchenko]

Aaron, thank you for revıew.								

> +Internals
> +---------
> +VP behaves as dictionary object, with strings keys and values.
> +Every property therefore could be expressed as pair ``key = value``.
> +Clients of VP "knows" what each property means, and what set of
> 
> I think this would be better as "VP does not provide any particular
> meaning for key/value pairs. Clients may assert a meaning for themselves."
> 
> Also, I'd like to see namespaces for properties.

What do you mean? What kind of namespaces you want?
We can use almost any string as key in dictionary, so one can easily
use 

svn:eol
svn:encoding

or 

bzr.eol
bzr.encoding 

keys, that will looks like namespaced ones.
İs not this enough?

/me simply dont understand how to implement namespaces for VP.

İ say almost any string because for human-readable format we cannot
accept keys wıth equal sign inside.

> 
> 
> +Serialization
> +-------------
> +VP stored inside inventory. For serialization is proposed to using bencode.
> 
> I would like to see a lot more detail than that. Especially, I'd like
> to understand how you intend to store them in the repository. Bencoded?
> Why not using xml? It's quite good at key/value pairs.

İ think we should store VP as part of inventory. Because VP is highly tied
to ınventory entries.

> +
> +This means, in particular, there is need to implement new dirstate format,
> +so dirstate file will keep current VP and last committed VP.
> 
> And presumably a new repository format.

This part is not clear for me: why? İf VP will be a part of inventory then we dont need new repository format, do we?

> +Format
> +~~~~~~
> +Format is very close to format of configuration files.
> 
> What are the differences?

There is no DEFAULT section.

> + Each section name is path of file relative to
> +WT root.
> 
> This is somewhat brittle; if a file is moved before the HRF version is
> updated, the association with path will be lost.

İMO HRF will be used the most to resolve conflicts.
When file moved we could update HRF as well.

> +2. Values as multiline strings is possible but not recommended,
> + because it also complicate human-readable format. For now
> + multiline strings will be represented as in RIO format.
> 
> Our config file format does support multiline strings, so I don't think
> it's necessary to switch to RIO here.

OK.

> 
> +Keep defaults in properties of directory entries
> +------------------------------------------------
> 
> This seems like a strange idea to me. I would expect most properties to
> be grouped by file type, not directory location.
> 
> Also, this is not our usual access pattern and may not be performant.

Alexander
(from Turkey vacation)