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

Reply via email to