Hi All, I started writing a proof of concept for this idea but have a time crunch and won't be working on it again for a few weeks so I'm putting it out here in case it sparks interest/debate.
Definition of "binary": File for which no automatic merging is viable. Motive: concurrent editing of binary files is problematic and can lead to lost work. This is a real bummer for some of us. Assumptions: 1. The team is cohesive and *wants* to not collide. I.e. big brother approach not needed 2. Removing write permissions to the locked files is adequate control. 3. Having some screen output when locks are changed is desirable but not critical. 4. Regular syncing is occurring (here fossil shines). Overall idea: A new command group is added to fossil e.g. "fossil lock subcmd options/operands" A wiki page "fossil_file_locks" is retrieved, updated and pushed back when files are locked or unlocked. My proof of concept will be implemented as a setuid wrapper program that calls fossil and accesses the server repo using a special UserId/password. The wiki page holds a sexp with lists of lockable files, lock state and if locked who owns the lock. The sexp is human readable and locks can potentially be edited by hand if necessary. Remember, this is to keep honest people who don't want to collide, honest. Not a control freak mechanism. I know it can be worked around and that is fine. Sales pitch: I'm pretty sure there are a lot of people who would love this if it was a built in feature of fossil. If there is someone on the list hankering to do some coding and if Richard bought off on the idea it would make those of us who need this very happy :) If no one takes this on I'll get back on it once I get though this busy spell. My code will be openly available but unfortunately for the paren-phobic it will be in Chicken Scheme, though easy to build and install and I will make a statically complied version available. The comments/outline from fsl.scm: ;; get the first argument if it exists ;; if it is lock then call the locking code with the second argument if it exists ;; if it is update, ci, co, checkin, checkout, or open then handle the before and after operation ;; update ;; get list of files to be touched ;; get wiki page data file_locks ;; chmod u+w affected files that are locked ;; fossil update ;; chmod a-w affected files that are locked ;; ;; ci, checkin ;; get list of files to be checked in, have to handle remaining command line args ;; get wiki page data file_locks ;; if any files to be checked in are locked, abort and tell user why ;; else do the checkin ;; co, checkout ;; get wiki page data file_locks ;; chmod a+w all locked files ;; fossil co ;; chmod a-w all locked files except any locks user has ;; lock ;; add ;; get wiki page data file_locks ;; add files or paths passed in as args to the file_locks list ;; remove duplicates ;; put wiki page data back in fossil ;; chmod a-w added files and recursively on added directories ;; release ;;
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
