RE: implementing basic metadata in cvs using tags

[Matthew Herrmann]

Hi Paul, (and Greg),

Thanks for your comments. The main idea was to wrap CVS in another layer of
script which would invisibly filter out the tag information. I agree that it
would be messy to use tags in the long run.

I think your suggestion sounds like a good one of adding info to RCS works,
since compatibility with that product is a non-issue for me.

These thoughts came to my mind as I saw the meta-information support in
Subversion and I looked for a way to integrate these into CVS (just mainly
interest related, not out of a burning need for a feature immediately).

Arguably it _is_ for a build system to register libraries etc., but as I
work in interpreted languages where the compilation is usually incremental
(check out libraries+source, work on interpreted source using compiled
libraries, compile everything for deployment), a 'build' system as such
except for the specific case of deployment doesn't really make sense, since
you usually compile about 20% of it.

I would still like to tie 3rd-party operations into checking out files
automatically, if possible. Can this be done using the existing admin files?

Regards,

Matthew Herrmann
-------------------------------------------
Far Edge Technology

tel: +612 9955 3640

11/80 Mount St
North Sydney NSW 2060
Australia

-----Original Message-----
From: Paul Sander [mailto:address@hidden
Sent: Sunday, 14 October 2001 19:09
To: address@hidden; address@hidden
Subject: Re: implementing basic metadata in cvs using tags


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:

Example:
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.

Example:
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).

Example:
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