summaryrefslogtreecommitdiff
path: root/Command/Move.hs
Commit message (Collapse)AuthorAge
* hlintGravatar Joey Hess2013-09-25
| | | | test suite still passes
* mirror: New command, makes two repositories contain the same set of files.Gravatar Joey Hess2013-08-20
| | | | | | | | | | | | | | This is a simple approach for setting up a mirroring repository. It will work with any type of remotes. Mirror --from is more expensive than mirror --to in general. OTOH, mirror --from will get the file from any remote that has it, not only the named mirror remote. And if the named mirror remote is not the fastest available remote with a file, that can speed things up. It would be possible to make the assistant or watch command do a more dynamic mirroring, that didn't need to scan every time.
* moved AssociatedFile definitionGravatar Joey Hess2013-07-04
|
* --unused: New switch that makes git-annex operate on all data found by the ↵Gravatar Joey Hess2013-07-03
| | | | last run of git annex unused. Supported by fsck, get, move, copy.
* --all for get, move, and copyGravatar Joey Hess2013-07-03
|
* connect existing meters to the transfer log for downloadsGravatar Joey Hess2013-04-11
| | | | | | | | | | | | | | Most remotes have meters in their implementations of retrieveKeyFile already. Simply hooking these up to the transfer log makes that information available. Easy peasy. This is particularly valuable information for encrypted remotes, which otherwise bypass the assistant's polling of temp files, and so don't have good progress bars yet. Still some work to do here (see progressbars.mdwn changes), but this is entirely an improvement from the lack of progress bars for encrypted downloads.
* add section metadata to all commandsGravatar Joey Hess2013-03-24
| | | | Not yet used .. mindless train work.
* two types of byNameGravatar Joey Hess2013-03-05
| | | | | | | | Clean up from 5123a1a83aa3b954fe67629508bab5ccea0e4148. In some cases, looking up a remote by name even though it has no UUID is desirable. This includes git annex sync, which can operate on remotes without an annex, and XMPP pairing, which runs addRemote (with calls byName) before the UUID of the XMPP remote has been configured in git.
* copy: Update location log when no copy was performed, if the location log ↵Gravatar Joey Hess2013-02-26
| | | | was out of date.
* proper fix for dropunusedGravatar Joey Hess2013-02-15
| | | | | | | | | | Now getKeysPresent checks that the key's content, not only its directory, exists. In direct mode, the inode cache file is used as a standin for the content. removeAnnex always removes the inode cache file, and drop and move --from always call removeAnnex, even if the object does not seem to be inAnnex, to ensure it's always deleted.
* More commands work in direct mode repositories: find, whereis, move, copy, ↵Gravatar Joey Hess2013-01-05
| | | | | | | | drop, log. These started working, for free, once lookupFile supported direct mode. yay!!
* block all commands that don't work in direct modeGravatar Joey Hess2012-12-29
| | | | | I left status working in direct mode, although it doesn't show correct stats for known annex keys.
* where indentationGravatar Joey Hess2012-11-12
|
* copy: avoid updating location log when no copy is performedGravatar Joey Hess2012-09-24
| | | | | git annex copy --to remote often does not need to copy a file, but it was still updating the location log in this case.
* make the assistant retry failed transfersGravatar Joey Hess2012-09-23
| | | | | | | When a transfer fails, the progress info can be used to intelligently retry it. If the transfer managed to make some progress, but did not fully complete, then there's a good chance that a retry will finish it (or at least make more progress).
* keep logs of failed transfers, and requeue them when doing a non-full scanGravatar Joey Hess2012-08-23
| | | | of a remote
* record transfer information on local git remotesGravatar Joey Hess2012-07-01
| | | | | | | | | | | | | | | In order to record a semi-useful filename associated with the key, this required plumbing the filename all the way through to the remotes' storeKey and retrieveKeyFile. Note that there is potential for deadlock here, narrowly avoided. Suppose the repos are A and B. A sends file foo to B, and at the same time, B gets file foo from A. So, A locks its upload transfer info file, and then locks B's download transfer info file. At the same time, B is taking the two locks in the opposite order. This is only not a deadlock because the lock code does not wait, and aborts. So one of A or B's transfers will be aborted and the other transfer will continue. Whew!
* get, move, copy: Now refuse to do anything when the requested file transfer ↵Gravatar Joey Hess2012-07-01
| | | | | | | | | | | | | | | is already in progress by another process. Note this is per-remote, so trying to get the same file from multiple remotes can still let duplicate downloads run. (And uploading the same file to multiple remotes is not duplicate at all of course.) get, move, and copy are the only git-annex subcommands that transfer files, but there's still git-annex-shell recvkey and sendkey to deal with too. I considered modifying retrieveKeyFile or getViaTmp, but they are called by other code that does not involve expensive file transfers (migrate) or that does file transfers that should not be checked by this (fsck --from).
* hlintGravatar Joey Hess2012-06-12
|
* added ifM and nuked 11 lines of codeGravatar Joey Hess2012-03-14
| | | | no behavior changes
* move --from, copy --from: 10 times faster scanning remote on local diskGravatar Joey Hess2012-02-26
| | | | | | | | | | | | | | | | | | | Rather than go through the location log to see which files are present on the remote, it simply looks at the disk contents directly. I benchmarked this speeding up scanning 834 files, from an annex on my phone's SSD, from 11.39 seconds to 1.31 seconds. (No files actually moved.) Also benchmarked 8139 files, from an annex on spinning storage, speeding up from 103.17 to 13.39 seconds. Note that benchmarking with an encrypted annex on flash actually showed a minor slowdown with this optimisation -- from 13.93 to 14.50 seconds. Seems the overhead of doing the crypto needed to get the filenames to directly check can be higher than the overhead of looking up data in the location log. (Which says good things about how well the location log and git have been optimised!) It *may* make sense to make encrypted local remotes not have hasKeyCheap set; further benchmarking is called for.
* 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.
* add tmp flag parameter to retrieveKeyFileGravatar Joey Hess2012-01-19
|
* fsck --fromGravatar Joey Hess2012-01-19
| | | | | | | | | | | | | | | | Fscking a remote is now supported. It's done by retrieving the contents of the specified files from the remote, and checking them, so can be an expensive operation. (Several optimisations are possible, to speed it up, of course.. This is the slow and stupid remote fsck to start with.) Still, if the remote is a special remote, or a git repository that you cannot run fsck in locally, it's nice to have the ability to fsck it. If you have any directory special remotes, now would be a good time to fsck them, in case you were hit by the data loss bug fixed in the previous release!
* tweakGravatar Joey Hess2012-01-06
|
* look up --to and --from remote names only onceGravatar Joey Hess2012-01-06
| | | | This will speed up commands like move and drop.
* more command-specific optionsGravatar Joey Hess2012-01-06
| | | | | | | | | | | | | | | | | | | | | Made --from and --to command-specific options. Added generic storage for values of command-specific options, which allows removing some of the special case fields in AnnexState. (Also added generic storage for command-specific flags, although there are not yet any.) Note that this storage uses a Map, so repeatedly looking up the same value is slightly more expensive than looking up an AnnexState field. But, the value can be looked up once in the seek stage, transformed as necessary, and passed in a closure to the start stage, and this avoids that overhead. Still, I'm hesitant to use this for things like force or fast flags. It's probably best to reserve it for flags that are only used by a few commands, or options like --from and --to that it's important only be allowed to be used with commands that implement them, to avoid user confusion.
* type alias cleanupGravatar Joey Hess2011-12-31
|
* inverted logicGravatar Joey Hess2011-12-09
|
* factor out a stopUnlessGravatar Joey Hess2011-12-09
| | | | code melt for lunch
* comment updateGravatar Joey Hess2011-11-20
|
* avoid error message when doing get --from on file not present on remoteGravatar Joey Hess2011-11-18
|
* lintGravatar Joey Hess2011-11-11
|
* better limiting of start actions to only run whenAnnexedGravatar Joey Hess2011-11-10
| | | | | Mostly only refactoring, but this does remove one redundant stat of the symlink by copy.
* tweakGravatar Joey Hess2011-11-10
|
* Optimized copy --from and get --from to avoid checking the location log for ↵Gravatar Joey Hess2011-11-10
| | | | | | | files that are already present. This can be a significant speedup when running in large trees that are only missing a few files; it makes copy --from just as fast as get.
* 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.)
* clean up check selection codeGravatar Joey Hess2011-10-29
| | | | | | | | | This new approach allows filtering out checks from the default set that are not appropriate for a command, rather than having to list every check that is appropriate. It also reduces some boilerplate. Haskell does not define Eq for functions, so I had to go a long way around with each check having a unique id. Meh.
* drop --from is now supported to remove file content from a remote.Gravatar Joey Hess2011-10-28
|
* refactored and generalized pre-command sanity checkingGravatar Joey Hess2011-10-27
|
* 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
|
* factor out common importsGravatar Joey Hess2011-10-03
| | | | no code changes
* remove command type definitionsGravatar Joey Hess2011-09-15
| | | | | | | These were a mistake, they make the type signatures harder to read and less flexible. The CommandSeek, CommandStart, CommandPerform, and CommandCleanup types were a good idea, but composing them with the parameters expected is going too far.
* add error for move --autoGravatar Joey Hess2011-09-15
| | | | | | | | | | | | | | | It probably does not make sense to enable auto mode for move. I cannot think of a situation where it would make sense to try to use it. A hypothetical auto mode for move would only differ from a normal move in one case -- when both repositories have a file, move deletes it from one, and this reduces the number of copies. So an auto mode would either only let move work in that situation, or avoid removing the file in that situation, depending on the number of copies. This would be complex to implement, and is perhaps not a very obvious behavior. The error is a good thing to have, so users don't expect it to do something it does not.
* clean up params in usage displayGravatar Joey Hess2011-09-15
|