forge/Vervis
1
0
Fork 0
Code Pull requests Activity
Vervis/src/Darcs/Local/Repository.hs

98 lines
3.1 KiB
Haskell
Raw Normal View History

Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
{- This file is part of Vervis.
-
Install darcs post-apply hooks in darcs repos, no-op hook for now In Darcs, any command can have a post hook (and a pre hook), and the hook command can be set using a command-line option to the darcs command that you run. So, in the Vervis SSH server, if we add a --posthook option when running `darcs apply` to apply remotely received patches, we get a chance to process the patch data much like in the git post-receive hook. The setup this patch creates is similar to the git one: It writes a _darcs/prefs/defaults file to all Darcs repos, and that defaults file sets the posthook line for `darcs apply`. The posthook line simply executes the actual hook program written in Haskell. The current hook program is a one-liner that prints a line to stdout, so every time you `darcs push` you can tell the hook got executed. The next step is to implement the actual hook logic, by reading patch data from the environment variable in which Darcs puts it.
2019-10-07 16:05:52 +02:00
- Written in 2016, 2019 by fr33domlover <fr33domlover@riseup.net>.
Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
-
- ♡ Copying is an act of love. Please copy, reuse and share.
-
- The author(s) have dedicated all copyright and related and neighboring
- rights to this software to the public domain worldwide. This software is
- distributed without any warranty.
-
- You should have received a copy of the CC0 Public Domain Dedication along
- with this software. If not, see
- <http://creativecommons.org/publicdomain/zero/1.0/>.
-}
Darcs change log view
2016-05-08 16:28:03 +02:00
module Darcs.Local.Repository
Install darcs post-apply hooks in darcs repos, no-op hook for now In Darcs, any command can have a post hook (and a pre hook), and the hook command can be set using a command-line option to the darcs command that you run. So, in the Vervis SSH server, if we add a --posthook option when running `darcs apply` to apply remotely received patches, we get a chance to process the patch data much like in the git post-receive hook. The setup this patch creates is similar to the git one: It writes a _darcs/prefs/defaults file to all Darcs repos, and that defaults file sets the posthook line for `darcs apply`. The posthook line simply executes the actual hook program written in Haskell. The current hook program is a one-liner that prints a line to stdout, so every time you `darcs push` you can tell the hook got executed. The next step is to implement the actual hook logic, by reading patch data from the environment variable in which Darcs puts it.
2019-10-07 16:05:52 +02:00
( writeDefaultsFile
, createRepo
Refactor git source view code and implement the same for Darcs
2016-05-05 09:29:19 +02:00
, readPristineRoot
Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
)
where
Upgrade LTS from 5.13 to 6.5
2016-07-02 10:51:29 +02:00
import Darcs.Util.Hash
Install darcs post-apply hooks in darcs repos, no-op hook for now In Darcs, any command can have a post hook (and a pre hook), and the hook command can be set using a command-line option to the darcs command that you run. So, in the Vervis SSH server, if we add a --posthook option when running `darcs apply` to apply remotely received patches, we get a chance to process the patch data much like in the git post-receive hook. The setup this patch creates is similar to the git one: It writes a _darcs/prefs/defaults file to all Darcs repos, and that defaults file sets the posthook line for `darcs apply`. The posthook line simply executes the actual hook program written in Haskell. The current hook program is a one-liner that prints a line to stdout, so every time you `darcs push` you can tell the hook got executed. The next step is to implement the actual hook logic, by reading patch data from the environment variable in which Darcs puts it.
2019-10-07 16:05:52 +02:00
import Data.Bits
import Data.Text (Text)
Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
import System.Directory (createDirectory)
import System.Exit (ExitCode (..))
import System.FilePath ((</>))
Darcs change log view
2016-05-08 16:28:03 +02:00
import System.IO (withBinaryFile, IOMode (ReadMode))
Install darcs post-apply hooks in darcs repos, no-op hook for now In Darcs, any command can have a post hook (and a pre hook), and the hook command can be set using a command-line option to the darcs command that you run. So, in the Vervis SSH server, if we add a --posthook option when running `darcs apply` to apply remotely received patches, we get a chance to process the patch data much like in the git post-receive hook. The setup this patch creates is similar to the git one: It writes a _darcs/prefs/defaults file to all Darcs repos, and that defaults file sets the posthook line for `darcs apply`. The posthook line simply executes the actual hook program written in Haskell. The current hook program is a one-liner that prints a line to stdout, so every time you `darcs push` you can tell the hook got executed. The next step is to implement the actual hook logic, by reading patch data from the environment variable in which Darcs puts it.
2019-10-07 16:05:52 +02:00
import System.Posix.Files
Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
import System.Process (createProcess, proc, waitForProcess)
Refactor git source view code and implement the same for Darcs
2016-05-05 09:29:19 +02:00
import qualified Data.ByteString as B
Install darcs post-apply hooks in darcs repos, no-op hook for now In Darcs, any command can have a post hook (and a pre hook), and the hook command can be set using a command-line option to the darcs command that you run. So, in the Vervis SSH server, if we add a --posthook option when running `darcs apply` to apply remotely received patches, we get a chance to process the patch data much like in the git post-receive hook. The setup this patch creates is similar to the git one: It writes a _darcs/prefs/defaults file to all Darcs repos, and that defaults file sets the posthook line for `darcs apply`. The posthook line simply executes the actual hook program written in Haskell. The current hook program is a one-liner that prints a line to stdout, so every time you `darcs push` you can tell the hook got executed. The next step is to implement the actual hook logic, by reading patch data from the environment variable in which Darcs puts it.
2019-10-07 16:05:52 +02:00
import qualified Data.Text as T
import qualified Data.Text.IO as TIO
writeDefaultsFile :: FilePath -> FilePath -> Text -> Text -> IO ()
writeDefaultsFile path cmd sharer repo = do
let file = path </> "_darcs" </> "prefs" </> "defaults"
TIO.writeFile file $ defaultsContent cmd sharer repo
setFileMode file $ ownerReadMode .|. ownerWriteMode
where
defaultsContent :: FilePath -> Text -> Text -> Text
defaultsContent hook sharer repo =
T.concat ["apply posthook ", T.pack hook, " ", sharer, " ", repo]
Refactor git source view code and implement the same for Darcs
2016-05-05 09:29:19 +02:00
Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
{-
initialRepoTree :: FileName -> DirTree B.ByteString
initialRepoTree repo =
Dir repo
[ Dir "_darcs"
--[ File "format"
-- "hashed|no-working-dir\n\
-- \darcs-2"
--, File "hashed_inventory" ""
--, File "index" ???
, Dir "inventories" []
, Dir "patches" []
, Dir "prefs" []
-- [ File "binaries" ""
-- , File "boring" ""
-- , File "motd" ""
-- ]
, Dir "pristine.hashed" []
]
]
-}
-- | initialize a new bare repository at a specific location.
Split git repo source handler into sane small functions
2016-05-04 19:17:47 +02:00
createRepo
Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
:: FilePath
-- ^ Parent directory which already exists
-> String
-- ^ Name of new repo, i.e. new directory to create under the parent
Install darcs post-apply hooks in darcs repos, no-op hook for now In Darcs, any command can have a post hook (and a pre hook), and the hook command can be set using a command-line option to the darcs command that you run. So, in the Vervis SSH server, if we add a --posthook option when running `darcs apply` to apply remotely received patches, we get a chance to process the patch data much like in the git post-receive hook. The setup this patch creates is similar to the git one: It writes a _darcs/prefs/defaults file to all Darcs repos, and that defaults file sets the posthook line for `darcs apply`. The posthook line simply executes the actual hook program written in Haskell. The current hook program is a one-liner that prints a line to stdout, so every time you `darcs push` you can tell the hook got executed. The next step is to implement the actual hook logic, by reading patch data from the environment variable in which Darcs puts it.
2019-10-07 16:05:52 +02:00
-> FilePath
-- ^ Path of Vervis hook program
-> Text
-- ^ Repo sharer textual ID
-> Text
-- ^ Repo textual ID
Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
-> IO ()
Install darcs post-apply hooks in darcs repos, no-op hook for now In Darcs, any command can have a post hook (and a pre hook), and the hook command can be set using a command-line option to the darcs command that you run. So, in the Vervis SSH server, if we add a --posthook option when running `darcs apply` to apply remotely received patches, we get a chance to process the patch data much like in the git post-receive hook. The setup this patch creates is similar to the git one: It writes a _darcs/prefs/defaults file to all Darcs repos, and that defaults file sets the posthook line for `darcs apply`. The posthook line simply executes the actual hook program written in Haskell. The current hook program is a one-liner that prints a line to stdout, so every time you `darcs push` you can tell the hook got executed. The next step is to implement the actual hook logic, by reading patch data from the environment variable in which Darcs puts it.
2019-10-07 16:05:52 +02:00
createRepo parent name cmd sharer repo = do
Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
let path = parent </> name
createDirectory path
Specify repodir in `darcs init`, otherwise it fails If `darcs init` isn't given a `--repodir`, even if you do specify the new repository's path, it complains that it can't run inside a repository, because it's running from a darcs clone of Vervis itself. If the repo dir is specified using `--repodir` instead, Darcs doesn't complain. That's at least the situation with 2.8.5, didn't check other versions.
2016-08-04 10:00:29 +02:00
let settings = proc "darcs" ["init", "--no-working-dir", "--repodir", path]
Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
(_, _, _, ph) <- createProcess settings
ec <- waitForProcess ph
case ec of
Install darcs post-apply hooks in darcs repos, no-op hook for now In Darcs, any command can have a post hook (and a pre hook), and the hook command can be set using a command-line option to the darcs command that you run. So, in the Vervis SSH server, if we add a --posthook option when running `darcs apply` to apply remotely received patches, we get a chance to process the patch data much like in the git post-receive hook. The setup this patch creates is similar to the git one: It writes a _darcs/prefs/defaults file to all Darcs repos, and that defaults file sets the posthook line for `darcs apply`. The posthook line simply executes the actual hook program written in Haskell. The current hook program is a one-liner that prints a line to stdout, so every time you `darcs push` you can tell the hook got executed. The next step is to implement the actual hook logic, by reading patch data from the environment variable in which Darcs puts it.
2019-10-07 16:05:52 +02:00
ExitSuccess -> writeDefaultsFile path cmd sharer repo
Enable Darcs repo creation using the executable Darcs does export most of its module tree, but there's a problem: Darcs relies on the current directory. It changes the current directory of the process to the repo, and then proceeds using paths relative to the repo dir. This is bad for my case here. If some other thread uses a relative path (e.g. currently any repo path is relative by default) in parallel, it will fail. For now, the quick path around this problem is to use the `darcs` program.
2016-05-04 13:44:06 +02:00
ExitFailure n -> error $ "darcs init failed with exit code " ++ show n
Refactor git source view code and implement the same for Darcs
2016-05-05 09:29:19 +02:00
readPristineRoot :: FilePath -> IO (Maybe Int, Hash)
readPristineRoot darcsDir = do
let inventoryFile = darcsDir </> "hashed_inventory"
Darcs change log view
2016-05-08 16:28:03 +02:00
line <- withBinaryFile inventoryFile ReadMode B.hGetLine
Refactor git source view code and implement the same for Darcs
2016-05-05 09:29:19 +02:00
let hashBS = B.drop 9 line
return (Nothing, decodeBase16 hashBS)
Copy permalink