Versioned metadata

[Jan Hudec]

Hello All,

There are several kinds of versioned metadata, implemented, under work
or proposed:

  * Executable flag
  * Ignore list
  * Subtree URL list
  * Tags
  * Keyword expansion flag(s)
  * Line endings conversion type
  * Charset conversion type
  
Besides someone might come with a, possibly problem specific, request
and should be able to implement it with a plugin.

The above metadata can be separated into three categories:

  * Independently versioned metadata:
    This is metadata that are versioned (stored in a weave/knit), but
    not related to particular revisions. Latest version of this metadata
    is in effect unless particular revision is specifically requested.
    To this category belongs:
    + Tags
    + Subtree URL list
  * Whole-tree metadata:
    This is metadata pertaining to the whole tree. To this category
    may belong the Ignore list and/or the Subtree URL list. I think
    Subtree URL list is better off in the first one and Ignore list is
    better in the next.
  * InventoryEntry metadata:
    To this category belongs:
    + Exectuable flag (already implemented)
    + Ignore list (though if it's thought to be too confusing, it can be
      made whole-tree).
    + Keyword expansion flag(s)
    + Line endings conversion type
    + Charset conversion type

The third category is quite populated, so I'd like to propose a bit of
common infrastructure for it:

 - InventoryEntry would get a properties list, in a way similar to how
   it now has the executable attribute.
 - Each element of that list would be an object, descendant of Property.
   These objects would have common interface providing:
   - serialize/deserialize for storing it in inventory.
   - method to find the value from working dir (default implementation
     would just get it from the inventory, for cases where it's set
     explicitly (for now all except executable flag)
   - method to apply the value to working dir ( would be a no-op except
     for executable flag)
   - method to merge that property.
 - Changeset/TreeTransform/merge core and other code that needs to deal
   with it would call know to use that interface.
 - There would be an 'UnknownProperty', that would serialize/deserialize
   by simply keeping the XML chunk, compare with the inventory content,
   not apply to working dir and abort a merge if not equal in both
   revisions. It would also print a warning whenever created.

   This is a backward-compatibility measure. Client that does not
   support some property would be able to read a branch using the
   property, commit to it and even merge it as long as the property is
   not changed. Of course unset properties would not be written not to
   cause problems. This means that adding a property would not require
   inventory version bump nor a branch version bump and could be even
   allowed from plugins. I can imagine eg. a plugin using this to store
   full unix permissions for uses like tracking /etc.

I'd like to start hacking on this and use it for the final part of the
new ignore system. However I'd like to hear some opinions on it first.

Regards,

Jan

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060209/e5d731da/attachment.pgp