Structural Informatics Group (SIG) logo
Home | Projects | Demos | Downloads | Publications | Local Info | About Us | New site
Go to the first, previous, next, last section, table of contents.

Sharing Issues

This method of code sharing is based on the ideas used in CVS, concurrent versions systems. I (jfb) tried to get CVS working for slisp but found that, although it worked, it was very unforgiving when I made a mistake or when I deleted or renamed a directory. Perhaps someone else can get this working, since our current approach does not allow for revision control, which will have to be done for now just by freezing versions of the entire slisp archive in seperate compressed tar files.

Another approach that I looked at was allowing the slisp archive to be shared while code was being compiled. That is, a programmer would only have local copies of those modules he was modifying, and would link to source code in the nfs mounted archive.

The advantages of this are 1) only a single copy of shared code would exist, and 2) some space would be saved.

The disadvantages are 1) this mechanism is not yet implemented and we've spent too much time on this already 2) Any change added by a programmer to the shared archive will be immediately seen by all others who use the archive, which may mean that a person's application will break 3) If a programmer desires to download a version of slisp that is not on the net then the shared archive will also have to be downloaded.

The main reason we didn't look at this alternative is that it would take time to implement, and we first need to see how useful slisp will be before we make it work better. This whole area is of course related to CASE, and we probably should be implementing this all in some commercial CASE tool.

Go to the first, previous, next, last section, table of contents.