If a system like that could be used, that had version management as well as locking, that might be ideal. Of course, cvs could be used in combination with your idea.
Dave
Stuart Brorson wrote:
Hello --
This is a simple lockfile proposal for gEDA/gaf.
While driving to work the other day, I realized that gEDA/gaf should implement a lockfile mechanism. Please find my thoughts about that here, along with a lockfile proposal. I am interested in hearing any comments -- yea or nay -- from the gEDA developer community.
Lockfiles are necessary because people will (hopefully) use gschem and gattrib together to manage their schematics. They may indeed run them simultaneously in two separate windows. Running these two programs simultaneously means that version skew problems can occur, e.g. when the user saves his data in gattrib, continues working on it there, but then edits the data in gschem and saves it out. Apparently, "Clock" Kulhavy has already done this.
Also, in larger, networked installations, people might want to edit the same file simultaneously without knowing about each other. This possibility must be met and managed. This is admittedly a corporate scenario which is removed from gEDA's current userbase, but why not architect for it up front?
To solve this problem, I propose a simple lockfile mechanism. The details are given below. I will code it myself & stick it into the appropriate libgeda, gschem, and gattrib fcns. First, however, I thought I'd get some reaction out of the developer community about what they thought about my scheme.
The lockfiles will be based on the name of each opened .sch file. Example: schematic_1.sch.lock. There will be one lock file per opened .sch file. If you are editing a multi-page design, then you will have multiple lock files. The lockfiles will live in the same directory as the associated .sch files.
Lockfiles will be simple ASCII text. Inside each lockfile, there will be the following (for example): ------------------------------------------------------ # This is a gEDA/gaf lockfile signalling that this .sch file # has been locked for editing. If you are sure that nobody # is currently editing this file, you may delete this lockfile # to use gEDA/gaf normally. # # user who locked this file user=sdb # process number of program creating this lock pid=345345 # program name which created this lock program=gattrib # time when lock was created timestamp=YYYYMMDD.HHSS -------------------------------------------------------
GEDA/gaf program behavior when using lockfiles:
1. Upon opening new file, program can optionally tell user that it is locked by another user, and give him the other user's info (UID, program used, timestamp of last save). Is this useful to the user, or just confusing?
2. Upon attempting to save a .sch file, first look for lockfile on this particular .sch file. Then:
3a. If no lockfile exists, create a lockfile with all program info in it. Then save out the .sch file normally. 3b. If lockfile exists, read it & check to see if *this* program & pid was the last program to save this file. Then: * If so, update lockfile & save normally. * Otherwise, it means that another user or pid or program is still using the file. Therefore, throw up this dialog box: ------------------------------------------------------ Warning, this file has been previously locked by user (user) using the program (other program) who last saved it on YYYYMMDD, at HHSS. If you save using (this program) now, you may corrupt data for that user. Click "cancel" to cancel this save operation and find out why this file is locked. Otherwise, you may overwrite the saved file by clicking "overwrite".
If you believe that this file should not be locked, you may simply delete the lockfile /path/to/filename.sch.lock and reattempt saving your file. ------------------------------------------------------ If the user selects cancel, just exit the file save dialog. Otherwise, update lockfile, and save.
4. Upon leaving the program, loop through all schematic pages and check to see if a lockfile exists for this file using this prog & pid. If so, delete the lockfile. This clears the .sch.lock file so that others can freely write.
The nice thing about this scheme, IMHO, is that it is transparent & simple. And if you kill your program abnormally, you can always just delete the associated lock file & run it again normally.
Comments?
Stuart
-- David J. Grant http://www.davidgrant.ca:81
begin:vcard fn:David Grant n:Grant;David adr:;;;Richmond;BC;;Canada email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE url:http://www.davidgrant.ca:81 version:2.1 end:vcard
