gitty.pl -- Single-file GIT like version system
This library provides a first implementation of a lightweight versioned file store with dynamic meta-data. The store is partly modelled after GIT. Like GIT, it uses a content-based store. In fact, the stored objects are compatible with GIT. Unlike GIT though, there are no trees. Each entry (file) has its own history. Each commit is associated with a dict that can carry aribitrary meta-data. The following fields are reserved for gitties bookkeeping:
- name:Name
- Name of the entry (file)
- time:TimeStamp
- Float representing when the object was added to the store
- data:Hash
- Object hash of the contents
- previous:Hash
- Hash of the previous commit.
The key commit
is reserved and returned as part of the meta-data of
the newly created (gitty_create/5) or updated object (gitty_update/5).
- gitty_open(+Store, +Options) is det
- Open a gitty store according to Options. Defined
options are:
- driver(+Driver)
- Backend driver to use. One of
files
orbdb
. When omitted and the store exists, the current store is examined. If the store does not exist, the default isfiles
.
- gitty_close(+Store) is det
- Close access to the Store.
- gitty_file(+Store, ?File, ?Head) is nondet
- True when File entry in the gitty store and Head is the HEAD revision.
- gitty_create(+Store, +Name, +Data, +Meta, -Commit) is det
- Create a new object Name from Data and meta information.
- gitty_update(+Store, +Name, +Data, +Meta, -Commit) is det
- Update document Name using Data and the given meta information
- gitty_data(+Store, +NameOrHash, -Data, -Meta) is semidet
- Get the data in object Name and its meta-data
- gitty_commit(+Store, +NameOrHash, -Meta) is semidet
- True if Meta holds the commit data of NameOrHash. A key
commit
is added to the meta-data to specify the commit hash. - gitty_history(+Store, +NameOrHash, -History, +Options) is det
- History is a list of dicts representating the history of Name in
Store. Options:
- depth(+Depth)
- Number of entries in the history. If not present, defaults to 5.
- includes(+HASH)
- Ensure Hash is included in the history. This means that the history includes the entry with HASH an (depth+1)//2 entries after the requested HASH.
- gitty_hash(+Store, ?Hash) is nondet
- True when Hash is an object in the store.
- gitty_reserved_meta(?Key) is nondet
- True when Key is a gitty reserved key for the commit meta-data
- is_gitty_hash(@Term) is semidet
- True if Term is a possible gitty (SHA1) hash
- gitty_diff(+Store, ?Hash1, +FileOrHash2OrData, -Dict) is det
- True if Dict representeds the changes in Hash1 to FileOrHash2.
If Hash1 is unbound, it is unified with the
previous
of FileOrHash2. Returns _{initial:true} if Hash1 is unbound and FileOrHash2 is the initial commit. Dict contains:- from:Meta1
- to:Meta2
- Meta-data for the two diffed versions
- data:UDiff
- String holding unified diff representation of changes to the data. Only present of data has changed
- tags:_45110{added:AddedTags, deleted:DeletedTags}
- If tags have changed, the added and deleted ones.
- data_diff(+Data1, +Data2, -UDiff) is det
- Diff two data strings line-by-line. UDiff is a list of terms of
the form below, where L1 and L2 provide the starting line in
Data1 and Data2 and S1 and S2 provide the number of affected
lines.
udiff(L1,S1,L2,S2,Diff)
Diff is a list holding
- + Line
- Line was added to Data1 to get Data2
- - Line
- Line was deleted from Data1 to get Data2
- Line1 - Line2
- Line was replaced
- =(Line)
- Line is identical (context line).
- udiff_string(+UDiff, -String) is det
- True when String is the string representation of UDiff.