summaryrefslogtreecommitdiff
path: root/Annex/Content.hs
Commit message (Collapse)AuthorAge
* getKeysPresent is now fully lazyGravatar Joey Hess2012-03-11
| | | | | | | | | | | | .. Allowing it to be used by things in constant space! Random statistics: git annex status has gone from taking 239 mb of memory and 26 seconds in a repo, to 8 mb and 13 seconds. The trick here is the unsafeInterleaveIO, and the form of the function's recursion, which I cribbed heavily from System.IO.HVFS.Utils.recurseDirStat. The difference is, this one goes to a limited depth and avoids statting everything.
* status: Fixed to run in nearly constant space.Gravatar Joey Hess2012-03-11
| | | | | | | | Before, it leaked space due to caching lists of keys. Now all necessary data about keys is calculated as they stream in. The "nearly constant" is due to getKeysPresent, which builds up a lot of [] thunks as it traverses .git/annex/objects/. Will deal with it later.
* configure: Check if ssh connection caching is supported by the installed ↵Gravatar Joey Hess2012-02-25
| | | | version of ssh and default annex.sshcaching accordingly.
* improve alwayscommit=false modeGravatar Joey Hess2012-02-25
| | | | | | | | | | | | | | Now changes are staged into the branch's index, but not committed, which avoids growing a large journal. And sync and merge always explicitly commit, ensuring that even when they do nothing else, they commit the staged changes. Added a flag file to indicate that the branch's journal contains uncommitted changes. (Could use git ls-files, but don't want to run that every time.) In the future, this ability to have uncommitted changes staged in the journal might be used on remotes after a series of oneshot commands.
* add annex.alwayscommit optionGravatar Joey Hess2012-02-25
| | | | | | To avoid commits of data to the git-annex branch after each command is run, set annex.alwayscommit=false. Its data will then be committed less frequently, when a merge or sync is done.
* Deal with NFS problem that caused a failure to remove a directory when ↵Gravatar Joey Hess2012-02-24
| | | | | | | | | | | | | | removing content from the annex. I was able to reproduce this on linux using the kernel's nfs server and mounting localhost:/. Determined that removing the directory fails when the just-deleted file in it was locked. Considered dropping the lock before removing the directory, but this would complicate parts of the code that should not need to worry about locking. So instead, ignore the failure to remove the directory in this case. While I was at it, made it attempt to remove both levels of hash directories, in case they're empty.
* IO exception reworkGravatar Joey Hess2012-02-03
| | | | | | ghc 7.4 comaplains about use of System.IO.Error to catch exceptions. Ok, use Control.Exception, with variants specialized to only catch IO exceptions.
* Avoid repeated location log commits when a remote is receiving files.Gravatar Joey Hess2012-01-28
| | | | | | | | | Done by adding a oneshot mode, in which location log changes are written to the journal, but not committed. Taking advantage of git-annex's existing ability to recover in this situation. This is used by git-annex-shell and other places where changes are made to a remote's location log.
* fsck --from remote --fastGravatar Joey Hess2012-01-20
| | | | | | | Avoids expensive file transfers, at the expense of checking file size and/or contents. Required some reworking of the remote code.
* optimise fsck --from normal git remotesGravatar Joey Hess2012-01-19
| | | | | | | | | | For a local git remote, can symlink the file. For a git remote using rsync, can preseed any local content. There are a few reasons to use fsck --from on a normal git remote. One is if it's using gitosis or similar, and you don't have shell access to run git annex locally. Another reason could be if you just want to fsck certian files of a bare remote.
* add a configure check for StatFSGravatar Joey Hess2012-01-15
| | | | | | | | | | | | This way, the build log will indicate whether StatFS can be relied on. I've tested all the failing architectures now, and on all of them, the StatFS code now returns Nothing, rather than Just nonsense. Also, if annex.diskreserve is set on a platform where StatFS is not working, git-annex will complain. Also, the Makefile was missing the sources target used when building with cabal.
* Added remote.name.annex-web-options configuration setting, which can be used ↵Gravatar Joey Hess2012-01-02
| | | | to provide parameters to whichever of wget or curl git-annex uses (depends on which is available, but most of their important options suitable for use here are the same).
* hslintGravatar Joey Hess2011-12-09
|
* add support for using hashDirLower in addition to hashDirMixedGravatar Joey Hess2011-11-28
| | | | | | | | | | Supporting multiple directory hash types will allow converting to a different one, without a flag day. gitAnnexLocation now checks which of the possible locations have a file. This means more statting of files. Several places currently use gitAnnexLocation and immediately check if the returned file exists; those need to be optimised.
* support .git/annex on a different disk than the rest of the repoGravatar Joey Hess2011-11-28
| | | | | | | | | | | | | | | | | | The only fully supported thing is to have the main repository on one disk, and .git/annex on another. Only commands that move data in/out of the annex will need to copy it across devices. There is only partial support for putting arbitrary subdirectories of .git/annex on different devices. For one thing, but this can require more copies to be done. For example, when .git/annex/tmp is on one device, and .git/annex/journal on another, every journal write involves a call to mv(1). Also, there are a few places that make hard links between various subdirectories of .git/annex with createLink, that are not handled. In the common case without cross-device, the new moveFile is actually faster than renameFile, avoiding an unncessary stat to check that a file (not a directory) is being moved. Of course if a cross-device move is needed, it is as slow as mv(1) of the data.
* lintGravatar Joey Hess2011-11-11
|
* factored out some useful error catching methodsGravatar Joey Hess2011-11-10
|
* better message when content is lockedGravatar Joey Hess2011-11-10
|
* exclusive locks, ughGravatar Joey Hess2011-11-09
|
* content lockingGravatar Joey Hess2011-11-09
| | | | | I've tested that this solves the cyclic drop problem. Have not looked at cyclic move, etc.
* safer inannex checkingGravatar Joey Hess2011-11-09
| | | | | | | | git-annex-shell inannex now returns always 0, 1, or 100 (the last when it's unclear if content is currently in the index due to it currently being moved or dropped). (Actual locking code still not yet written.)
* reorg to allow taking content lockGravatar Joey Hess2011-11-09
| | | | | | | The lock will only persist during the perform stage, so the content must be removed from the annex then, rather than in the cleanup stage. (No lock is actually taken yet.)
* cleanupGravatar Joey Hess2011-11-09
|
* reorder repo parameters lastGravatar Joey Hess2011-11-08
| | | | | | | | | | | | | Many functions took the repo as their first parameter. Changing it consistently to be the last parameter allows doing some useful things with currying, that reduce boilerplate. In particular, g <- gitRepo is almost never needed now, instead use inRepo to run an IO action in the repo, and fromRepo to get a value from the repo. This also provides more opportunities to use monadic and applicative combinators.
* break out non-log stuff to separate moduleGravatar Joey Hess2011-10-15
|
* reorganize log modulesGravatar Joey Hess2011-10-15
| | | | no code changes
* minor syntax changesGravatar Joey Hess2011-10-11
|
* renameGravatar Joey Hess2011-10-05
|
* renameGravatar Joey Hess2011-10-04