[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Meta-meta-data?

From: Rob Hubbard <rob.hubbard_at_softel.co.uk>
Date: Tue, 15 Sep 2009 13:40:04 +0100

Hello,

This is just a rough, "blue sky" idea for Subversion.

I remember reading somewhere how some users of SVN make very
heavy-weight use of properties. For example, an image file might have a
property called "thumb" whose value is a reduced-size version of the
image. The property value is not merely some text, but binary data, and
in this case it is (the contents of) a full-blown file.

To my mind, this file-like-property ought to be able have its own
meta-data.

(I suppose that this is already possible *indirectly* by using further
associated properties. For example, there could be something like a
"thumb:svn:mime-type" property on the image too.)

Subversion does a wonderful job of providing a small number of simple
concepts capable of expressing many more-complex ideas. So, for example,
the file copy may be used to branch, and to tag; therefore, a separate
concept of label is not required (although some work must be done, or
scripts written, when "data-mining"). Meta-data also provides for
potential implementations of labelling, on either versioned or
unversioned properties.

However, properties introduce an artificial distinction in SVN between
files and properties.

I wonder whether a future version of SVN (post 1.x) might simplify this.
(By simplify, I'm thinking in terms of a user's viewpoint, not the
implementation!)

At the moment, a node in the repository has various attributes including
        Node Kind: directory / file / ...

Perhaps this could be supplemented with a new attribute
        Metalevel: yes / no

Rather than having files
        mypath/ [Node kind = directory]
        mypath/myfile.jpg [Node kind = file]
with properties such as
        svn:ignore
        svn:needs-lock
        svn:mime-type
and so on, you might use nodes
        mypath/svn!ignore [Node kind = file; Metalevel = yes]
        mypath/myfile.jpg/svn!needs-lock [Node kind = file; Metalevel =
yes]
        mypath/myfile.jpg/svn!mime-type.txt [Node kind = file; Metalevel
= yes]

Note that I have allowed for the possibility of meta-data to be
directories. Note also that I have not used ":" in the property name as
that character can't be used in filenames.

A variant, making use of the directories would be:
        mypath/svn/ [Node kind = directory; Metalevel = yes]
        mypath/svn/ignore [Node kind = file; Metalevel = no]
        mypath/myfile.jpg/svn/ [Node kind = file; Metalevel = yes]
        mypath/myfile.jpg/svn/needs-lock [Node kind = file; Metalevel =
no]
        mypath/myfile.jpg/svn/mime-type.txt [Node kind = file; Metalevel
= no]

The basic idea would be that these objects would not be checked out by
default. They could be accessed as usual using proplist, propget,
propset, and so on. However, the SVN depth concept could be extended
into this "meta-space". Then, these properties could be checked out, and
manipulated with any chosen application.

The metadata could be considered to be on an almost orthogonal axis to
that of the data. There could be --meta-depth and --set-meta-depth
options (which default to "empty"). [It would not be orthogonal in the
same way that revisions are, as the meta data are rooted on the data.]

One problem is of course, that you can't have a *file* with path
        mypath/myfile.jpg/svn!mime-type.txt
because
        mypath/myfile.jpg
exists as a file and not a directory. Therefore this file would need to
map onto something else on the filing system. I'm not sure what that
should be, but perhaps it should be configurable. Possibilities are:
        mypath/myfile.jpg.meta/svn!mime-type.txt
        mypath/myfile.jpg!svn!mime-type.txt
        mypath/.meta/myfile.jpg/svn!mime-type.txt
Unfortunately, none of these completely avoids the potential of
"blocking" nodes in the filing system; those would need to be dealt with
as they are with updates, merges and checks-out.

On the other hand,
        mypath/svn!ignore
would be alright so long as that does not coincide with a file of the
same name.

Another problem is what should happen if propset is used on a property
that has been "checked out", but I suppose that the file representing it
should be updated.

This scheme would allow meta-data of meta-data, such as:
        mypath/myfile.jpg/thumb.jpg/svn!needs-lock [Node kind = file;
Metalevel = yes]
        mypath/myfile.jpg/thumb.jpg/svn!mime-type.txt [Node kind = file;
Metalevel = yes]

It would also allow non-meta-data of meta-data:
        mypath/myfile.jpg/thumb.jpg/note.txt [Node kind = file;
Metalevel = no]

Finally, this all addresses versioned properties only. I'm not sure how
this would work for unversioned properties; those might need to be
retained.

Well, this is just an idea that I hope the development community will
consider and even find useful. Any criticism or other comment from SVN
developers or other users alike is welcome.

Thanks for an excellent version control tool,
Rob.

Rob Hubbard

________________________________________________________________
This message has been independently scanned for the Softel Group and cleared of containing viruses and other malicious data.

Powering Television Beyond the Video (TM)

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395033

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-15 14:40:59 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.