2de50f733a
The commit thread now has access to a channel containing the times of all uncommitted changes. This lets it be smart about detecting busy times when a batch job is running (such as rm -rf, or untarring something, etc), and avoid committing until it's done. While at the same time, instantly committing one-off changes that the user is going to expect to see immediately. I had to use STM to implement the channel, because of http://hackage.haskell.org/trac/ghc/ticket/4154 While this adds a dependency, I always wanted to use STM, so this actually makes me happy. ;) Also happy that shouldCommit is a pure function, so other commit smartness strategies can easily be played with. Although the current one seems pretty good. There is one bug, for some reason it does double commits, every time.
58 lines
1.7 KiB
Text
58 lines
1.7 KiB
Text
Source: git-annex
|
|
Section: utils
|
|
Priority: optional
|
|
Build-Depends:
|
|
debhelper (>= 9),
|
|
ghc (>= 7.4),
|
|
libghc-missingh-dev,
|
|
libghc-hslogger-dev,
|
|
libghc-pcre-light-dev,
|
|
libghc-sha-dev,
|
|
libghc-dataenc-dev,
|
|
libghc-http-dev,
|
|
libghc-utf8-string-dev,
|
|
libghc-hs3-dev (>= 0.5.6),
|
|
libghc-testpack-dev,
|
|
libghc-quickcheck2-dev,
|
|
libghc-monad-control-dev (>= 0.3),
|
|
libghc-lifted-base-dev,
|
|
libghc-json-dev,
|
|
libghc-ifelse-dev,
|
|
libghc-bloomfilter-dev,
|
|
libghc-edit-distance-dev,
|
|
libghc-hinotify-dev,
|
|
libghc-stm-dev,
|
|
ikiwiki,
|
|
perlmagick,
|
|
git,
|
|
uuid,
|
|
rsync,
|
|
openssh-client,
|
|
Maintainer: Joey Hess <joeyh@debian.org>
|
|
Standards-Version: 3.9.3
|
|
Vcs-Git: git://git.kitenet.net/git-annex
|
|
Homepage: http://git-annex.branchable.com/
|
|
|
|
Package: git-annex
|
|
Architecture: any
|
|
Section: utils
|
|
Depends: ${misc:Depends}, ${shlibs:Depends},
|
|
git (>= 1:1.7.7),
|
|
uuid,
|
|
rsync,
|
|
wget | curl,
|
|
openssh-client (>= 1:5.6p1)
|
|
Suggests: graphviz, bup, gnupg
|
|
Description: manage files with git, without checking their contents into git
|
|
git-annex allows managing files with git, without checking the file
|
|
contents into git. While that may seem paradoxical, it is useful when
|
|
dealing with files larger than git can currently easily handle, whether due
|
|
to limitations in memory, time, or disk space.
|
|
.
|
|
Even without file content tracking, being able to manage files with git,
|
|
move files around and delete files with versioned directory trees, and use
|
|
branches and distributed clones, are all very handy reasons to use git. And
|
|
annexed files can co-exist in the same git repository with regularly
|
|
versioned files, which is convenient for maintaining documents, Makefiles,
|
|
etc that are associated with annexed files but that benefit from full
|
|
revision control.
|