#git #lock #version-control #cli #build-tool

build git-lock

Please use gix-<thiscrate> instead (‘git’ -> ‘gix’)

16 releases (10 stable)

3.0.3 Feb 17, 2023
3.0.1 Dec 19, 2022
3.0.0 Nov 21, 2022
2.2.0 Nov 17, 2022
0.1.0 Jun 23, 2021

#121 in #version-control

Download history 1385/week @ 2023-06-03 883/week @ 2023-06-10 1113/week @ 2023-06-17 1174/week @ 2023-06-24 1235/week @ 2023-07-01 1382/week @ 2023-07-08 964/week @ 2023-07-15 1057/week @ 2023-07-22 882/week @ 2023-07-29 906/week @ 2023-08-05 825/week @ 2023-08-12 927/week @ 2023-08-19 827/week @ 2023-08-26 696/week @ 2023-09-02 987/week @ 2023-09-09 1098/week @ 2023-09-16

3,788 downloads per month
Used in 17 crates (4 directly)

MIT/Apache

61KB
1K SLoC

Use lock-files in the way git does with auto-cleanup being the most notable feature.

  • writable lock files that can be committed to atomically replace the resource they lock
  • read-only markers that lock a resource without the intend to overwrite it
  • auto-removal of the lockfiles and intermediate directories on drop or on signal

lib.rs:

git-style registered lock files to make altering resources atomic.

In this model, reads are always atomic and can be performed directly while writes are facilitated by a locking mechanism implemented here.

Lock files mostly git-tempfile with its auto-cleanup and the following:

  • consistent naming of lock files
  • block the thread (with timeout) or fail immediately if a lock cannot be obtained right away
  • commit lock files to atomically put them into the location of the originally locked file

Limitations

  • As the lock file is separate from the actual resource, locking is merely a convention rather than being enforced.
  • The limitations of git-tempfile apply.

Dependencies

~1–12MB
~115K SLoC