Versioned metadata

[Jan Hudec]

On Thu, Feb 09, 2006 at 10:44:19 -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jan Hudec wrote:
> > 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
> 
> There's also been some talk about annotating revisions.  This could
> allow people to safely ajust commit messages, or to note that, say, a
> particular revision introduced a bug, received a +1 from Robert Collins,
> etc.

Yes, that makes a fourth type. If revisions are to be lumped into single
knit, than that knit should be able to support it.

> >   * InventoryEntry metadata:
> 
> Perhaps also a binary flag or MIME type.  For example, no jpeg image
> should ever have a text merge performed on it, even if its contents are
> all alphanumeric.

Yes. That's all more stuff that applies to InventoryEntry.

> > 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.
> 
> Hmm.  I'm not sure about this.  It would be nice to be able to do scalar
> merges on all properties, regardless of type.  But scalar three-way and
> scalar weave merge are very different.

Well, some properties are lists and some are scalars. The list ones are lists
of independent scalars though, fortunately. So there would be two bases, one
for scalar and one for list properties.

The problem I realized just few minutes ago is, that I really think it should
be a /weave/ (scalar) merge -- and I am not sure the weave/knit will be able
to help much when it's all lumped together in a single weave, more so that
inventory is XML, which is not line-based.

> >  - 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. 
> 
> I would prefer if we handled unknown properties using scalar three-way
> or scalar weave merge, as appropriate.  That would handle the simple cases.

It would do, if we at least knew whether the property is a list or scalar,
which we would, because the XML used would be slightly different.

> > 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.
> 
> Personally, I like having all the ignore data in one place, rather than
> scattered throughout the inventory.  I recognize that putting it in the
> inventory means moves perform a bit more nicely, but it also restricts
> flexability, since you can't refer to directories that don't currently
> exist.
> 
> Say you have a directory for each architecture, and you want to ignore
> some of the files.  I think this is impossible using directory properties:
> ./arch/*/*.lo

I actually meant to leave the possibility for whole-path patterns in. So the
above could be:
arch/*/*.lo
attached on root, or
*/*.lo
attached on arch.
Yes, it sounds like it could be quite confusing, unfortunately. On the other
if we some day allow checking out subtrees (and it sounds useful to do), the
former won't be valid if someone branches arch only, but the later will.

-- 
						 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/c8677ef6/attachment.pgp