git-annex/Assistant/Drop.hs

{- git-annex assistant dropping of unwanted content
 -
 - Copyright 2012 Joey Hess <id@joeyh.name>
 -
 - Licensed under the GNU AGPL 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
import Types.NumCopies

{- Drop from local and/or remote when allowed by the preferred content and
 - numcopies settings. -}
handleDrops :: Reason -> Bool -> Key -> AssociatedFile -> [VerifiedCopy] -> Assistant ()
handleDrops reason fromhere key f preverified = do
	syncrs <- syncDataRemotes <$> getDaemonStatus
	locs <- liftAnnex $ loggedLocations key
	liftAnnex $ handleDropsFrom locs syncrs reason fromhere key f preverified 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			`-`
update licenses from GPL to AGPL This does not change the overall license of the git-annex program, which was already AGPL due to a number of sources files being AGPL already. Legally speaking, I'm adding a new license under which these files are now available; I already released their current contents under the GPL license. Now they're dual licensed GPL and AGPL. However, I intend for all my future changes to these files to only be released under the AGPL license, and I won't be tracking the dual licensing status, so I'm simply changing the license statement to say it's AGPL. (In some cases, others wrote parts of the code of a file and released it under the GPL; but in all cases I have contributed a significant portion of the code in each file and it's that code that is getting the AGPL license; the GPL license of other contributors allows combining with AGPL code.) 2019-03-13 19:48:14 +00:00			`- Licensed under the GNU AGPL version 3 or higher.`
split 2012-10-18 19:22:28 +00:00			`-}`

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 VerifiedCopy data type There should be no behavior changes in this commit, it just adds a more expressive data type and adjusts code that had been passing around a [UUID] or sometimes a Maybe Remote to instead use [VerifiedCopy]. Although, since some functions were taking two different [UUID] lists, there's some potential for me to have gotten it horribly wrong. 2015-10-08 20:55:11 +00:00			`import Types.NumCopies`
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 VerifiedCopy data type There should be no behavior changes in this commit, it just adds a more expressive data type and adjusts code that had been passing around a [UUID] or sometimes a Maybe Remote to instead use [VerifiedCopy]. Although, since some functions were taking two different [UUID] lists, there's some potential for me to have gotten it horribly wrong. 2015-10-08 20:55:11 +00:00			`handleDrops :: Reason -> Bool -> Key -> AssociatedFile -> [VerifiedCopy] -> Assistant ()`
			`handleDrops reason fromhere key f preverified = 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`
add VerifiedCopy data type There should be no behavior changes in this commit, it just adds a more expressive data type and adjusts code that had been passing around a [UUID] or sometimes a Maybe Remote to instead use [VerifiedCopy]. Although, since some functions were taking two different [UUID] lists, there's some potential for me to have gotten it horribly wrong. 2015-10-08 20:55:11 +00:00			`liftAnnex $ handleDropsFrom locs syncrs reason fromhere key f preverified callCommandAction`