Aaron Bentley wrote:
Unfortunately, commit is still an O(n) operation. It's just a faster
O(n) operation, because it uses the project tree to list all revisions
instead of using the archive.
I wonder whether the following modification of the revision locking
mechanism would work for O(1) commits.
An unlocked archive version directory contains a lock directory as follows:
foo--bar--1.0
|
+ ---- base-0
|
...
|
+ ---- patch-N
|
+ ---- ++version-lock
|
+ ---- last-revision
|
+ ---- +contents
where the file 'last-revision' in this example contains "patch-N".
During a commit, the client:
1. checks that the working tree is up-to-date by reading
++version-lock/last-revision
2. locks the version by renaming the ++version-lock directory
3. reads and checks the last-revision file against the working tree
again, computes the new revision name
4. copies the new change set into the +contents directory, then moves
it into its final revision directory
5. updates the last-revision file, creates a new +contents directory
6. renames the owned version lock directory back as ++version-lock,
which unlocks this version
I think that each step is almost what arch currently does (at least it
should), the fact that the lock directory remains a direct child of the
version directory excepted. This looks too easy, what did I miss?