git-annex/Assistant/Drop.hs

{- git-annex assistant dropping of unwanted content
 -
 - Copyright 2012 Joey Hess <id@joeyh.name>
 -
 - Licensed under the GNU GPL version 3 or higher.
 -}

module Assistant.Drop (
	handleDrops,
	handleDropsFrom,
) where

import Assistant.Common
import Assistant.DaemonStatus
import Annex.Drop (handleDropsFrom, Reason)
import Logs.Location
import CmdLine.Action

{- Drop from local and/or remote when allowed by the preferred content and
 - numcopies settings. -}
handleDrops :: Reason -> Bool -> Key -> AssociatedFile -> Maybe Remote -> Assistant ()
handleDrops reason fromhere key f knownpresentremote = do
	syncrs <- syncDataRemotes <$> getDaemonStatus
	locs <- liftAnnex $ loggedLocations key
	liftAnnex $ handleDropsFrom locs syncrs reason fromhere key f knownpresentremote callCommandAction
split 2012-10-18 19:22:28 +00:00			`{- git-annex assistant dropping of unwanted content`
			`-`
update my email address and homepage url 2015-01-21 16:50:09 +00:00			`- Copyright 2012 Joey Hess <id@joeyh.name>`
split 2012-10-18 19:22:28 +00:00			`-`
			`- Licensed under the GNU GPL version 3 or higher.`
			`-}`

sync --content: New option that makes the content of annexed files be transferred. Similar to the assistant, this honors any configured preferred content expressions. I am not entirely happpy with the implementation. It would be nicer if the seek function returned a list of actions which included the individual file gets and copies and drops, rather than the current list of calls to syncContent. This would allow getting rid of the somewhat reundant display of "sync file [ok\|failed]" after the get/put display. But, do that, withFilesInGit would need to somehow be able to construct such a mixed action list. And it would be less efficient than the current implementation, which is able to reuse several values between eg get and drop. Note that currently this does not try to satisfy numcopies when getting/putting files (numcopies are of course checked when dropping files!) This makes it like the assistant, and unlike get --auto and copy --auto, which do duplicate files when numcopies is not yet satisfied. I don't know if this is the right decision; it only seemed to make sense to have this parallel the assistant as far as possible to start with, since I know the assistant works. This commit was sponsored by Øyvind Andersen Holm. 2014-01-19 21:35:36 +00:00			`module Assistant.Drop (`
			`handleDrops,`
			`handleDropsFrom,`
			`) where`
split 2012-10-18 19:22:28 +00:00
			`import Assistant.Common`
check and drop unwanted content from remotes after receiving a transfer 2012-10-18 19:37:57 +00:00			`import Assistant.DaemonStatus`
sync --content: New option that makes the content of annexed files be transferred. Similar to the assistant, this honors any configured preferred content expressions. I am not entirely happpy with the implementation. It would be nicer if the seek function returned a list of actions which included the individual file gets and copies and drops, rather than the current list of calls to syncContent. This would allow getting rid of the somewhat reundant display of "sync file [ok\|failed]" after the get/put display. But, do that, withFilesInGit would need to somehow be able to construct such a mixed action list. And it would be less efficient than the current implementation, which is able to reuse several values between eg get and drop. Note that currently this does not try to satisfy numcopies when getting/putting files (numcopies are of course checked when dropping files!) This makes it like the assistant, and unlike get --auto and copy --auto, which do duplicate files when numcopies is not yet satisfied. I don't know if this is the right decision; it only seemed to make sense to have this parallel the assistant as far as possible to start with, since I know the assistant works. This commit was sponsored by Øyvind Andersen Holm. 2014-01-19 21:35:36 +00:00			`import Annex.Drop (handleDropsFrom, Reason)`
split 2012-10-18 19:22:28 +00:00			`import Logs.Location`
avoid using function named that conflicts with name used in newer version of process library 2014-01-29 17:44:53 +00:00			`import CmdLine.Action`
add additional debug info about reasons for drops 2013-03-01 19:58:44 +00:00
check and drop after uploads 2012-10-18 20:05:43 +00:00			`{- Drop from local and/or remote when allowed by the preferred content and`
typo 2012-12-05 16:32:26 +00:00			`- numcopies settings. -}`
add additional debug info about reasons for drops 2013-03-01 19:58:44 +00:00			`handleDrops :: Reason -> Bool -> Key -> AssociatedFile -> Maybe Remote -> Assistant ()`
			`handleDrops reason fromhere key f knownpresentremote = do`
don't try to transfer data to/from XMPP remotes Partition syncRemotes into ones needing git sync (ie, non-special remotes), and ones needing data sync (ie, non-XMPP remotes). 2012-11-11 20:23:16 +00:00			`syncrs <- syncDataRemotes <$> getDaemonStatus`
add additional debug info about reasons for drops 2013-03-01 19:58:44 +00:00			`locs <- liftAnnex $ loggedLocations key`
avoid using function named that conflicts with name used in newer version of process library 2014-01-29 17:44:53 +00:00			`liftAnnex $ handleDropsFrom locs syncrs reason fromhere key f knownpresentremote callCommandAction`