[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: implementing basic metadata in cvs using tags

From: Paul Sander
Subject: Re: implementing basic metadata in cvs using tags
Date: Sun, 14 Oct 2001 02:09:15 -0700

Do you really believe that overloading symbolic tags is a good idea?
What value do you set the special tags to?  Are users allowed to modify
them with the usual tag commands?  Do you want users to see them with the
usual log commands?  Do you want to prevent users from using them as
version selectors during checkout?  How do you guarantee that existing
tags won't happen to collide with newer special ones?

I believe that if you're going to the trouble to modify CVS to interpret
tags specially, then you may find that it's just as easy (perhaps easier)
to modify the RCS library to provide a general interface to per-file and
per-revision newphrases.  If this indeed is true, then there's little to be
gained from trying to bend an existing structure to a purpose for which
it's not intended.

Keep in mind also that great care must be taken in what kind of metadata
are stored.  Stuff that's not directly related to version control should
be left to the build system.  The COM stuff that you describe, for
example, might be best left to the build system.  Be wary of any post-
processing that would be needed if it's not directly related to getting
files in and out of the repository.  Unpacking tar files is on thing;
registering libraries with the OS is another.  Setting permissions is
little stickier; it's useful to have an interface to set permissions
as appropriate to the user performing the checkout (e.g. giving
execute permissions to executable programs), but complete access
control (e.g. the exact ownerships and modes on a Unix system) are
arguably outside the scope of the version control system and they're
too tied to the platform to be useful generally.

--- Forwarded mail from address@hidden

I just had a thought while reading people's emails about renames and
preserving unix permissions and so on, and an idea hit me:

why not have registered programs on the client side which mangle permissions
and so on into a sort of UUencoded string, put into a file's tag, which is
then read by the same program and reapplied when the file is checked out?

Here's the sketch of where you could use it and what you could do:

file has group read, group write, world read, world execute. Then, by some
mechanism, you specify that a given file is enabled for this form of tag
mangling. upon performing a commit, the client program GETPER say would read
the permissions, then encode them as XMKJ1J. That one file gets given the
tag "META_GETPER_XMKJ1J". When the file is checked out, the checking out
procedure knows by the magic "META_" that it needs to invoke the external
program on that file. It runs "GETPER" and passes it as a parameter the
filename and XMKJ1J. That program knows what to do with it and does so.

OCX and COM DLLs used in application may change as the application goes. As
an input to the project, they should be included so that you don't trash
your machines, re checkout your source and then not be able to compile
because they're missing. With this method, you could give them a "sticky
tag" called "COM_REGISTER", which then evokes an external program on
checkouts/updates and releases, appropriately registering and unregistering
the COM file. Maybe even database files could be attached/detached using a
similar mechanism? (not sure if this would be useful, but it feels like
there would be other similar uses).

Well, potentially (this would be a wrap over the top of cvs) -- you could
automatically record in a similar format the changes of filenames and then
have it intercept log commands to detect when filenames change.

Ie. it would store a tag at the point of the creation of the new file which
links back to the old file. cvs log is intercepted and generated for both
files. they are then somehow concatenated.

i recognise this is a much bigger problem but this feature could be a useful
stepping stone to getting that working.

Forces as I see it are:
- need sticky tags to exist in a non-branch context. I don't know if this
can be done? If so, then it's simple, I just add an appropriate IS-A tag to
a file, and then the appropriate programs are evoked at different points. If
this is unavailable, then the only practical way to say "this file's unix
permissions need to be tracked" is to either have some sort of per-module
list of files to operate on, or to say for example "all html files need to
have permissions tracked". We then say that "permissions tracked" means call
"GETPER" before commits to generate magic tags.

- check points where code could run before commits and so on. if this is
done as a patch, then this would be the way to go. if not, then this is not
necessary since the more messy 'wrap cvs' technique applies.

- need to be able to check the tags on checked out files in CVS. i think
this is available via cvs log but please let me know if i'm wrong

- need tags to be basically constant-time efficiency. a lot of this metadata
will get generated, so if it clags cvs then this approach won't work.

Could people please:
1. Suggest if there's a better way to solve the COM registration problem? I
remember something about the commitinfo and modules files specifying
applications to run... ? My offline copy of the cvs manual is broken so i
can't look it up.

2. Can I do this just by using built-in functionality or would I need to
patch or wrap?

3. Is this useful? It seems to me to solve the whole metadata problem -- you
can store file permissions for different platforms and other random
information that may be required.

People's comments would be greatly appreciated.

--- End of forwarded message from address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]