On Fri, Jan 21, 2005 at 07:51:19PM -0500, Stuart Brorson wrote: > 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 > -------------------------------------------------------
First, why use such a complicated file format? First, the timestamp could be gotten from the filesystem. Second, why not make the like files something like .filename.sch.pid.[as].lock, where the [as] is either an a or s for gattriv or gschem? Another possibility would be make .filename.sch.lock be a symlink to gattrib.pid, or perhaps better still gattrib.ip.pid. You could certainly stick a uid in, but then, can't you look up the uid from the pid? Of course, if you do that, you can't look up the uid when the process has ended. I'm really just asking why you aren't using the sorts of methods that I see other unix programs use. You probably have a very good reason that I'm not aware of since I certainly wouldn't call myself a major unix guru. As to coordinating multiple users, rather than just multiple programs under the same users on the same files, I think your plan is a bit weak. My first thought was to make multiple user coordination go through something like CVS. Designers can check out schematic files, and when they are done check them in. gscheme and gattrib could be given the ability to parse the diff files and walk the user through merging the changes. The advantage is that this project wouldn't have to write a new server, just client code to reuse an existing server infrastructure. Of course, something other than CVS could be used, like arch or subversion, depending on what people think is the best fit. However, upon more thought, that still seems somewhat weak. What about looking parts of design down while allowing others unlocked? For isntance, you make have a designer specializing in power supplies, analog signalling, and digital design, and it might be nice to lock each into their own part of the design. I don't know what may or may not be wanted. I'm just thinking about some of the stuff I've seen advertised from companies like Mentor. Still, many types of locking could perhaps be worked into a system based on CVS, but it might require splitting up what goes in what files (like having a design split over three files to allow the files to be locked individually be allowing certain users to only checkout files but not check changes back in. Anyway, I'm not trying to run over your idea, I'm just trying to explore some further ideas trying to think a bit further ahead into theoretical corporate markets. -- Joshua D. Boyd [EMAIL PROTECTED] http://www.jdboyd.net/ http://www.joshuaboyd.org/
