On Sat, Jan 22, 2005 at 12:37:24PM -0500, Stuart Brorson wrote: > Thanks to everybody for the outpouring of ideas! I appreciate it! Here are > some responses from me. > > Quoting Dan McMahill <[EMAIL PROTECTED]>: > > On Fri, Jan 21, 2005 at 07:51:19PM -0500, Stuart Brorson wrote:
> > You may wish to also record the hostname of the system that > > created the lock otherwise the pid may not be easy to do anything > > with. Also you may wish to include a version number of the lock > > file and perhaps the os/version of the system which placed > > the lock. > > Good idea. I'll put the host name in there too. > > > Also what do you think about automatic expiring of locks? > > For example if a program has a lock, it is required to once an > > hour update a time stamp in the lock file. Then perhaps > > if a time stamp is more than 2 hour old the lock file is > > declared invalid. This may help with the problem of stale > > lock files being left around if a program crashes or a > > computer or network goes down. > > Automatic expiration is getting too complicated for me. I understand the > problem you wish to avoid, but I think that the file-based mechanism is simple > enough that the user can just go and delete the lock file if there has been an > abnormal program termination or a network failure. Remember -- I am not the > world's greatest programmer, so I try to keep things simple. thats fair. It could be added later if needed. > Some other points: > > * Joshua suggested incorporated including the pid into the lockfile name. My > questions is: Why? Using only the schematic.sch.lock filename makes the lock > independent of which program or which pid created the lock. Then, any program > which wishes to write the file must only look to see if the corresponding > .lock > file exists. If I stick the pid in the filename, then I need to look for any > file of the form schematic.sch.*, which is a grep-style operation on the whole > directory from within a C program -- kind of a PITA if you ask me. > That's not to rubbish the idea. Rather, I am wonder what the advantage is of > having the pid in the filename. I do realize that other unix programs do > this, > but I don't know why they do, or what the advantage is. I'd just keep the pid in the file contents, not the name. > * As for the multiple suggestions to integrate this into a CVS type system, I > think that CVS is meant to solve a different problem. CVS is meant to > maintain > different versions of a particular file, whereas my simple lockfile scheme is > meant to prevent multiple programs from colliding when saving out .sch files. > > Yes, in the grand scheme of things, CVS also has facilities to handle version > skew and merges between different file versions, so the problems have some > commonality. However, here are my points about CVS: I think CVS's merging is nice for source code, but crappy for schematics. I'm a believer in the checkout/lock - edit - checkin/unlock model of version control for schematics and layout. But I agree that the whole design management question is different from the locking stuff here. > 1. Integrating CVS into gEDA/gaf's save system seems like a very complicated > coding job. Again, I am not the world's greatest developer. I just play with > this stuff for fun. Therefore, I eschew complexity. I also believe that most > simple things can be made to work, whereas most complicated things are doomed > to remain forever buggy. > > 2. Requiring users to have CVS up and running alongside gEDA/gaf would be a > major turn-off to many (perhaps most) gEDA users. I'd hazard to guess that > most gEDA users are students or hobbiests who just want to draw schematics. > They don't want to deal with CVS. Many of them probably don't even know what > it > is. Those who do want to use CVS can check stuff in manually -- which is what > they are already doing. > > Comments? I think the design management question is different from the locking question. I wouldn't mind eventually seeing some hooks in gschem for design management, but its really not too much effort right now to use CVS without out any integration. --
