While Mercurial is all about being decentralized, it is sometimes very useful to work in a centralized fashion: if the files you work on cannot be merged (binary files such as Word documents, Photoshop images, etc) then it is better to communicate upfront about any edits to avoid concurrent work.
Please see the documentation in the wiki for more information.
The lock extension is provided to the community AS IS, WITHOUT MAINTENANCE, according to the terms of the GPL version 2 or any later version ("GPLv2+"). While we appreciate feedback from the community, we will not provide user support, nor will we commit to providing fixes or even integrating fixes provided by others in the community.
0.5.6 — 2014-08-28
- This release is compatible with Mercurial 3.1 and older
0.5.5 — 2014-08-28
- This release is compatible with Mercurial 3.0 to 3.02
0.5.4 — 2014-04-02
- Adapt tests to Mercurial 2.9
0.5.3 — 2013-06-13
- Fix problems with Mercurial 2.5
0.5.2 — 2013-05-31
- This release is compatible with Mercurial 2.4 to 2.9.2
- Fixed problem with updatewriteperm option (a repo could not be cloned when it contained a lock from someone other than the current user and updatewriteperm was set)
- Fixed some typos
- Adapted test to changes in documentation
- Made tests timing-independent by using the NOW environment variable
0.5.1 — 2012-11-19
- This release is compatible with Mercurial 2.3 and older
- Added hg locks --all to show all locks on all branches (resolves issue #8)
- Fixed problem when loading hglock via projrc during inital clone
- Many improvements to the test suite (including issues #9 and #10)
- Fixed issue #11 which was related to the creation of the local repository
0.5 — 2011-10-20
Lock files on copy and rename. With our model, the server wont accept a push that involves unlocked files for which locking is mandatory, except for newly added files. Such files appear after a rename if the new file is not locked. However, the user cannot lock the file since it is not on the server yet.
The extension will now internally acquire a lock for the destination name of a rename or copy. For rename, the lock for the original file is left in place so that the user own locks for both the old and the new name.
Fixed Issue 3: File write permissions not updated on initial clone when an .hgignore file exists
Tested the extension with Mercurial versions 1.8.4 to 2.0 and rewrote code and tests to maintain compatibility.
0.4 — 2011-08-18
Experimental support for marking unlocked files as read-only. This is similar to how SVN works when a file has the svn:needs-lock property set.
This is not yet advertised in the extension help and is turned off by default. To enable, add the following to a configuration file:
[hglock] updatewriteperm = True
When a repository is cloned, files marked as needing locking (matched by .hglocks) will be checked out read-only. When a file is locked, it will be made writable. When a file is unlocked (with via hg unlock FILE or hg push), it will be read-only again.
Thanks to Scott Sturdivant for contributing this feature.
The update and commit commands use locks implicitly and will now silently ignore a missing or uninitialized lock repository. Before, hg update would abort if the lock repository was not initialized, it now outputs a warnings that is only shown when --verbose is used.
Refactored code for better maintainability. The remote procedure call protocol now lives in its own module.
0.3 — 2011-08-09
Client-side checking of pushed changesets. Before pushing, clients now inspects each outgoing changeset to see if it contains modifications to an unlocked file for which locking is mandatory. The push is aborted if such a changeset is found.
Make hg unlock validate the client's changeset the same way hg lock does. This ensures that a client does not unlock a file before the changesets that modify it have been pushed.
The primary way to unlock files is now to simply push the changesets that affect the files -- the unlock command can only be used if a file has not been modified since it was locked.
Disabled --force flag for hg push. Creating multiple heads on push is then no longer possible. Pushing a new branch is still possible with the --new-branch flag.
Fix compatibility with Mercurial 1.9.x. Now tested with Mercurial version 1.8.4, 1.9, and 1.9.1.
0.2 — 2011-07-22
Re-release of version 0.1.
The change from a changegroup hook to a pretxnchangegroup hook in 575c95b4ab8f had bad consequences. So 575c95b4ab8f and the followup fixes (d87f0dc0919e, 4ba9b24da91b, 7ec8374652ad) were too unstable to release.
0.1 — 2011-07-20
- First tagged release.
James Heard <firstname.lastname@example.org>