Hi people, 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. Regards, Matthew Herrmann ------------------------------------------- Far Edge Technology tel: +612 9955 3640 11/80 Mount St North Sydney NSW 2060 Australia _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
