Checkpoint 0.2b1 Released!
Ian Charnas
second developer's preview of Tortuga, I noticed a couple features
that we needed in Checkpoint. Namely, we needed to be able to
associate arbitrary metadata with file-system files. This allows us
to say (in Tortuga) that "this file should be indexed by the internal
search engine" or "that file is only visible to authenticated
users"... stuff like that.
For those following along at home, "easy_install -U Checkpoint" will
upgrade you to the new version, and you can test-drive Checkpoint
using the "getting started" guide:
http://code.google.com/p/checkpoint/wiki/GettingStarted
Now back to working on the second developer's preview.. thanks as
always for your patience, I work on this about 4 hours a day... every
day... and it IS getting done....
-Ian
Here's the CHANGELOG for those interested --
Checkpoint 0.2b1 - January 22, 2009
----------------------------------
* Changed behavior of @lock decorator
In earlier versions of Checkpoint, this decorator was used for
synchronization AND crash recovery purposes, and some problems came out of
that approach. Now, @lock is used only for synchronization.
* The `status` and `commit` commands now take an optional list of paths
For example, this means you can now check on the status of a particular
file, or commit a particular subdirectory. For each directory that's
specified in this list of paths, the directory will be walked recursively
to find or commit changes.
* Added propget, propset, propdel, and proplist commands
Users and developers can now associate metadata properties with files. In
order to support command-line usage and API usage at the same time,
property names and values must both be strings. To store basic python
types (lists, dicts, etc), it's recommended that API users use `repr` to
store values, and `eval` to get those values back.
SPECIAL NOTE: Because there's no cross-platform way to add filesystem
hooks that would allow us to detect renamed files, when a file is moved or
renamed it is detected as one file being DELETED and another being ADDED.
A consequence of this is that moving a file using regular filesystem tools
(like 'mv' and 'rename') will disassociate the file from its properties.
In order to move a file and keep the properties, a `move` command has been
added. Likewise a `copy` command will copy both the file and the
associated properties. Both of these commands take a list of paths, and
paths can be files, links, or entire directory structures.