[Gnu-arch-users] Re: arch with 'special files'

[John Meinel]

Josh England wrote:

> On Tue, 2005-03-29 at 11:01 +0200, Matthieu Moy wrote:
>  
>
> > Josh England <address@hidden> writes:
> >
> >    
> >
> > > I need to retain permissions on all files, 
> > >      
> > Permission *and* ownership (arch doesn't store ownership. Most
> > revision control systems won't because they're not designed to be used
> > as root).
> >    
>
> Of course.  However, I believe that full OS revision control is a
> legitimate need that Arch could be ideally suited for.  
>
> I'm pretty sure all the changes I'd like can be handled with more
> (optional) metadata.  I'm not against some scripting glue, but to do
> this I still need to be able to store/retrieve some metadata in the
> archive.
>
> How about this.  The 'file-metadata' and 'set-file-metadata' commands
> could be modified to take a single user-defined metadata string (a
> --userdef parameter?) which would be stored in the archive in some sane
> way (similar to symlinks maybe).  'tla update' and such could quietly
> ignore this string and not modify any files (or it could print a warning
> saying that user-defined metadata has changed) -- since it is
> user-defined, the user has to deal with it.  Changesets could simply
> reflect that this metadata string has changed for a file.  With this, I
> could add dummy files into the archive with enough metadata for a
> wrapper script to be able to convert to/from a device/fifo/whatever.
>
> Although an automatic --ownership flag would be nice, I can make do with
> a single archived metadata string and use hooks/wrappers to take care of
> the dirty work.
>
> -JE
>  
If you are asking for user-defined meta-data, how is this different from 
creating a user-defined text file listing the metadata that you are 
keeping track of. Then you have a wrapper which on commit, makes sure 
the metadata file is up-to-date, and on checkout runs a post-processing 
script to update whatever is necessary.

You still have user-permissions, you still have full tracking of 
everything you want to do, and you have it without modifying a single 
line of tla code.

I would even think that you could keep one file per directory. The 
wrapper scripts should be fairly simple. I mean the wrapper script could be:

#!/bin/bash
# This is a wrapper around tla commit which updates
# the metadata
for d in `find . -type d -print`; do
# This could also be something like
# for d in `tla inventory --source --dirs`; do
# this restricts you to tla controlled directories
# and doesn't go into junk dirs, etc.
# It als handles nested projects.
   metafile="$d/=metainfo"
   rm -f $metafile
   for f in $d/*; do
   # possibly should be
   # for f in `ls -d $d/* | sort`; do
      echo $f >> $metafile
      stat --statoptions $f >> $metafile
   done;
done;

# Now that we have updated the meta-info,
# check to make sure there are changes in the tree
# and then commit
if tla changes -q; then
   tla commit -s "$1"
fi

The update script just needs to be able to read that metadata file, and 
do what you need.

Personally, I would probably write the whole thing in python, and have 
fancier handling of different file-types. Also, the above script doesn't 
handle spaces/newlines in filenames, that is easier to handle in python 
as well. I was just showing how simple it is to get working, and shell 
is pretty good for that.

Then the update script just needs to know how to parse that file, and 
re-generate any files that you need. That seems a lot more reasonable 
than trying to modfy the changeset format, and a lot less work. It also 
can be used for just about any RCS.

John
=:->