[MERGE/RFC] Versioned properties spec

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Belchenko wrote:
> Alexander Belchenko пишет:
>> here is my proposal for versioned properties.
> 
> I apologize for my poor English skill.
> Here is slightly reworked version.
> 
> [µ]

bb:resubmit

+Overview
+========
+VP provide generic container for data, but not for arbitrary kind of data.

I think this isn't very clear, because on the "generic" side you talk
about the functional capabilities, but on the "arbitrary" side, you talk
about intended use.

+It's intended to store special internal data about content of files
+under version control. Although, VP will not check kind of data that it
holds.
+So if user wish he can store multi-hundred kilobytes contents in VP, and
+make performance much worse.

So you should say something like:
Although there is no restriction on content length, it will be optimized
for relatively short strings of data.



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


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


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


+Format
+~~~~~~
+Format is very close to format of configuration files.

What are the differences?

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

+Notes about properties values

Should by "property"

+-----------------------------
+1. Limitation to store values always as strings simplify implementation

"Limiting the stored values to strings only simplifies the
implementation of human-readable format a lot."

+   of human-readable format a lot. Despite that proposed serialization
                                    "Even though", not "Despite that"

+   mechanism allows to serialize integers as integers, and lists as lists,
+   VP allows only strings.
+
+   Allowing lists as valid type for values will complicate
                                           "would", not "will"

+   form. Also list of numbers or strings (as complete words) could be
packed

"Also, a list"

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

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

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGymvV0F+nu1YWqI0RAmBRAJ4p0jGBBFQ6qeYr/DLBgcYi4k/TRACeN4VT
tRD3ikavqNW/wIgIdV+PHp4=
=V8ml
-----END PGP SIGNATURE-----