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
(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
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
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
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 =
mypath/myfile.jpg/svn!mime-type.txt [Node kind = file; Metalevel
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 =
mypath/myfile.jpg/svn/mime-type.txt [Node kind = file; Metalevel
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
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:
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,
would be alright so long as that does not coincide with a file of the
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
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,
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)
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-15 14:40:59 CEST