naskya/vervis
1
0
Fork 0
mirror of https://code.naskya.net/repos/ndqEd synced 2025-01-11 00:56:46 +09:00
Code Activity
vervis/src/Darcs/Local/Repository.hs

99 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 20:44:06 +09:00
{- This file is part of Vervis.
-
Switch to new actor layout This is such a huge patch, it's probably impossible to tell what it does by looking at the code. One thing is clear: It changes *everything* :P so here's an overview: - There are now 5 types of actors, each having its own top-level route - So projects, repos, etc. are no longer "under" sharers - Actor routes are now based on their KeyHashid, there are no "idents" anymore, i.e. URLs look random and don't contain user or repo names - No sharers anymore; people and groups are distinct entities not sharing a common namespace or anything like that - Project has been renamed to Deck and it simply means a ticket tracker; repos are no longer "under" projects - In addition to Person, Group, Repo and Deck, there's a new actor type Loom, which is a patch tracker; i.e. Repo actors don't manage MRs anymore - All C2S and S2S is temporarily disabled, because huge changes to the whole code are required and I'll do them gradually in the next patches - Since form-based actions are implemented using C2S, they're disabled as well, so Vervis is now essentially read-only - Some views have been temporarily removed, e.g. repo history and commit view - A huge set of DB migrations has been added to adapt the DB to these changes; I haven't tested them yet on a read DB so there may be errors there; I'll fix them in the next patches if I find any (probably going to test on the main instance where Vervis itself is hosted...) - Some modules got tech upgrades, e.g. LocalActor became a higher-kinded type and a similar pattern is probably relevant for several other types - There's an 'Actor' entity in the DB schema now, and all 5 actor types use it for common things like inbox and outbox - Although inbox and outbox are used only by Actor, so essentially could be removed, I haven't removed them; that's because I wonder if at some point users can have a tree of inboxes much like in email; I don't have an excuse for Outbox, but anyway, leaving them as is for now - Workflows, roles and collaborators are partially removed/unused until I figure out a sane federated way to provide these features - Since repo routes don't contain a "sharer" anymore, SSH URIs are now simpler, they already look like user@host/repo regardless of who "controls" that repo
2022-08-15 22:57:42 +09:00
- Written in 2016, 2019, 2022 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 20:44:06 +09: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 23:28:03 +09: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 23:05:52 +09:00
( writeDefaultsFile
, createRepo
Refactor git source view code and implement the same for Darcs
2016-05-05 16:29:19 +09: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 20:44:06 +09:00
)
where
Upgrade LTS from 5.13 to 6.5
2016-07-02 17:51:29 +09: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 23:05:52 +09: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 20:44:06 +09:00
import System.Directory (createDirectory)
import System.Exit (ExitCode (..))
import System.FilePath ((</>))
Darcs change log view
2016-05-08 23:28:03 +09: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 23:05:52 +09: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 20:44:06 +09:00
import System.Process (createProcess, proc, waitForProcess)
Refactor git source view code and implement the same for Darcs
2016-05-05 16:29:19 +09: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 23:05:52 +09:00
import qualified Data.Text as T
import qualified Data.Text.IO as TIO
Switch to new actor layout This is such a huge patch, it's probably impossible to tell what it does by looking at the code. One thing is clear: It changes *everything* :P so here's an overview: - There are now 5 types of actors, each having its own top-level route - So projects, repos, etc. are no longer "under" sharers - Actor routes are now based on their KeyHashid, there are no "idents" anymore, i.e. URLs look random and don't contain user or repo names - No sharers anymore; people and groups are distinct entities not sharing a common namespace or anything like that - Project has been renamed to Deck and it simply means a ticket tracker; repos are no longer "under" projects - In addition to Person, Group, Repo and Deck, there's a new actor type Loom, which is a patch tracker; i.e. Repo actors don't manage MRs anymore - All C2S and S2S is temporarily disabled, because huge changes to the whole code are required and I'll do them gradually in the next patches - Since form-based actions are implemented using C2S, they're disabled as well, so Vervis is now essentially read-only - Some views have been temporarily removed, e.g. repo history and commit view - A huge set of DB migrations has been added to adapt the DB to these changes; I haven't tested them yet on a read DB so there may be errors there; I'll fix them in the next patches if I find any (probably going to test on the main instance where Vervis itself is hosted...) - Some modules got tech upgrades, e.g. LocalActor became a higher-kinded type and a similar pattern is probably relevant for several other types - There's an 'Actor' entity in the DB schema now, and all 5 actor types use it for common things like inbox and outbox - Although inbox and outbox are used only by Actor, so essentially could be removed, I haven't removed them; that's because I wonder if at some point users can have a tree of inboxes much like in email; I don't have an excuse for Outbox, but anyway, leaving them as is for now - Workflows, roles and collaborators are partially removed/unused until I figure out a sane federated way to provide these features - Since repo routes don't contain a "sharer" anymore, SSH URIs are now simpler, they already look like user@host/repo regardless of who "controls" that repo
2022-08-15 22:57:42 +09:00
writeDefaultsFile :: FilePath -> FilePath -> Text -> Text -> IO ()
writeDefaultsFile path cmd authority repo = do
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 23:05:52 +09:00
let file = path </> "_darcs" </> "prefs" </> "defaults"
Switch to new actor layout This is such a huge patch, it's probably impossible to tell what it does by looking at the code. One thing is clear: It changes *everything* :P so here's an overview: - There are now 5 types of actors, each having its own top-level route - So projects, repos, etc. are no longer "under" sharers - Actor routes are now based on their KeyHashid, there are no "idents" anymore, i.e. URLs look random and don't contain user or repo names - No sharers anymore; people and groups are distinct entities not sharing a common namespace or anything like that - Project has been renamed to Deck and it simply means a ticket tracker; repos are no longer "under" projects - In addition to Person, Group, Repo and Deck, there's a new actor type Loom, which is a patch tracker; i.e. Repo actors don't manage MRs anymore - All C2S and S2S is temporarily disabled, because huge changes to the whole code are required and I'll do them gradually in the next patches - Since form-based actions are implemented using C2S, they're disabled as well, so Vervis is now essentially read-only - Some views have been temporarily removed, e.g. repo history and commit view - A huge set of DB migrations has been added to adapt the DB to these changes; I haven't tested them yet on a read DB so there may be errors there; I'll fix them in the next patches if I find any (probably going to test on the main instance where Vervis itself is hosted...) - Some modules got tech upgrades, e.g. LocalActor became a higher-kinded type and a similar pattern is probably relevant for several other types - There's an 'Actor' entity in the DB schema now, and all 5 actor types use it for common things like inbox and outbox - Although inbox and outbox are used only by Actor, so essentially could be removed, I haven't removed them; that's because I wonder if at some point users can have a tree of inboxes much like in email; I don't have an excuse for Outbox, but anyway, leaving them as is for now - Workflows, roles and collaborators are partially removed/unused until I figure out a sane federated way to provide these features - Since repo routes don't contain a "sharer" anymore, SSH URIs are now simpler, they already look like user@host/repo regardless of who "controls" that repo
2022-08-15 22:57:42 +09:00
TIO.writeFile file $ defaultsContent cmd authority repo
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 23:05:52 +09:00
setFileMode file $ ownerReadMode .|. ownerWriteMode
where
Switch to new actor layout This is such a huge patch, it's probably impossible to tell what it does by looking at the code. One thing is clear: It changes *everything* :P so here's an overview: - There are now 5 types of actors, each having its own top-level route - So projects, repos, etc. are no longer "under" sharers - Actor routes are now based on their KeyHashid, there are no "idents" anymore, i.e. URLs look random and don't contain user or repo names - No sharers anymore; people and groups are distinct entities not sharing a common namespace or anything like that - Project has been renamed to Deck and it simply means a ticket tracker; repos are no longer "under" projects - In addition to Person, Group, Repo and Deck, there's a new actor type Loom, which is a patch tracker; i.e. Repo actors don't manage MRs anymore - All C2S and S2S is temporarily disabled, because huge changes to the whole code are required and I'll do them gradually in the next patches - Since form-based actions are implemented using C2S, they're disabled as well, so Vervis is now essentially read-only - Some views have been temporarily removed, e.g. repo history and commit view - A huge set of DB migrations has been added to adapt the DB to these changes; I haven't tested them yet on a read DB so there may be errors there; I'll fix them in the next patches if I find any (probably going to test on the main instance where Vervis itself is hosted...) - Some modules got tech upgrades, e.g. LocalActor became a higher-kinded type and a similar pattern is probably relevant for several other types - There's an 'Actor' entity in the DB schema now, and all 5 actor types use it for common things like inbox and outbox - Although inbox and outbox are used only by Actor, so essentially could be removed, I haven't removed them; that's because I wonder if at some point users can have a tree of inboxes much like in email; I don't have an excuse for Outbox, but anyway, leaving them as is for now - Workflows, roles and collaborators are partially removed/unused until I figure out a sane federated way to provide these features - Since repo routes don't contain a "sharer" anymore, SSH URIs are now simpler, they already look like user@host/repo regardless of who "controls" that repo
2022-08-15 22:57:42 +09:00
defaultsContent :: FilePath -> Text -> Text -> Text
defaultsContent hook authority repo =
Make the hook config file path include the instance host Before this patch, if you ran more than 1 instance as the same OS user, they'd use the same config file path and overwrite it and cause post hooks to have errors due to wrong config being used.
2019-10-20 18:19:49 +09:00
T.concat
[ "apply posthook "
Switch to new actor layout This is such a huge patch, it's probably impossible to tell what it does by looking at the code. One thing is clear: It changes *everything* :P so here's an overview: - There are now 5 types of actors, each having its own top-level route - So projects, repos, etc. are no longer "under" sharers - Actor routes are now based on their KeyHashid, there are no "idents" anymore, i.e. URLs look random and don't contain user or repo names - No sharers anymore; people and groups are distinct entities not sharing a common namespace or anything like that - Project has been renamed to Deck and it simply means a ticket tracker; repos are no longer "under" projects - In addition to Person, Group, Repo and Deck, there's a new actor type Loom, which is a patch tracker; i.e. Repo actors don't manage MRs anymore - All C2S and S2S is temporarily disabled, because huge changes to the whole code are required and I'll do them gradually in the next patches - Since form-based actions are implemented using C2S, they're disabled as well, so Vervis is now essentially read-only - Some views have been temporarily removed, e.g. repo history and commit view - A huge set of DB migrations has been added to adapt the DB to these changes; I haven't tested them yet on a read DB so there may be errors there; I'll fix them in the next patches if I find any (probably going to test on the main instance where Vervis itself is hosted...) - Some modules got tech upgrades, e.g. LocalActor became a higher-kinded type and a similar pattern is probably relevant for several other types - There's an 'Actor' entity in the DB schema now, and all 5 actor types use it for common things like inbox and outbox - Although inbox and outbox are used only by Actor, so essentially could be removed, I haven't removed them; that's because I wonder if at some point users can have a tree of inboxes much like in email; I don't have an excuse for Outbox, but anyway, leaving them as is for now - Workflows, roles and collaborators are partially removed/unused until I figure out a sane federated way to provide these features - Since repo routes don't contain a "sharer" anymore, SSH URIs are now simpler, they already look like user@host/repo regardless of who "controls" that repo
2022-08-15 22:57:42 +09:00
, T.pack hook, " ", authority, " ", repo
Make the hook config file path include the instance host Before this patch, if you ran more than 1 instance as the same OS user, they'd use the same config file path and overwrite it and cause post hooks to have errors due to wrong config being used.
2019-10-20 18:19:49 +09:00
]
Refactor git source view code and implement the same for Darcs
2016-05-05 16:29:19 +09: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 20:44:06 +09: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-05 02:17:47 +09: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 20:44:06 +09:00
:: FilePath
-- ^ Parent directory which already exists
C2S & UI: Allow creation of a new Repo
2022-09-16 19:34:44 +09:00
-> Text
-- ^ Repo keyhashid, 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 23:05:52 +09:00
-> FilePath
-- ^ Path of Vervis hook program
-> Text
Make the hook config file path include the instance host Before this patch, if you ran more than 1 instance as the same OS user, they'd use the same config file path and overwrite it and cause post hooks to have errors due to wrong config being used.
2019-10-20 18:19:49 +09:00
-- ^ Instance HTTP authority
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 20:44:06 +09:00
-> IO ()
C2S & UI: Allow creation of a new Repo
2022-09-16 19:34:44 +09:00
createRepo parent repo cmd authority = do
let path = parent </> T.unpack 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 20:44:06 +09:00
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 17:00:29 +09: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 20:44:06 +09:00
(_, _, _, ph) <- createProcess settings
ec <- waitForProcess ph
case ec of
Switch to new actor layout This is such a huge patch, it's probably impossible to tell what it does by looking at the code. One thing is clear: It changes *everything* :P so here's an overview: - There are now 5 types of actors, each having its own top-level route - So projects, repos, etc. are no longer "under" sharers - Actor routes are now based on their KeyHashid, there are no "idents" anymore, i.e. URLs look random and don't contain user or repo names - No sharers anymore; people and groups are distinct entities not sharing a common namespace or anything like that - Project has been renamed to Deck and it simply means a ticket tracker; repos are no longer "under" projects - In addition to Person, Group, Repo and Deck, there's a new actor type Loom, which is a patch tracker; i.e. Repo actors don't manage MRs anymore - All C2S and S2S is temporarily disabled, because huge changes to the whole code are required and I'll do them gradually in the next patches - Since form-based actions are implemented using C2S, they're disabled as well, so Vervis is now essentially read-only - Some views have been temporarily removed, e.g. repo history and commit view - A huge set of DB migrations has been added to adapt the DB to these changes; I haven't tested them yet on a read DB so there may be errors there; I'll fix them in the next patches if I find any (probably going to test on the main instance where Vervis itself is hosted...) - Some modules got tech upgrades, e.g. LocalActor became a higher-kinded type and a similar pattern is probably relevant for several other types - There's an 'Actor' entity in the DB schema now, and all 5 actor types use it for common things like inbox and outbox - Although inbox and outbox are used only by Actor, so essentially could be removed, I haven't removed them; that's because I wonder if at some point users can have a tree of inboxes much like in email; I don't have an excuse for Outbox, but anyway, leaving them as is for now - Workflows, roles and collaborators are partially removed/unused until I figure out a sane federated way to provide these features - Since repo routes don't contain a "sharer" anymore, SSH URIs are now simpler, they already look like user@host/repo regardless of who "controls" that repo
2022-08-15 22:57:42 +09:00
ExitSuccess -> writeDefaultsFile path cmd authority 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 20:44:06 +09: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 16:29:19 +09:00
readPristineRoot :: FilePath -> IO (Maybe Int, Hash)
readPristineRoot darcsDir = do
let inventoryFile = darcsDir </> "hashed_inventory"
Darcs change log view
2016-05-08 23:28:03 +09:00
line <- withBinaryFile inventoryFile ReadMode B.hGetLine
Refactor git source view code and implement the same for Darcs
2016-05-05 16:29:19 +09:00
let hashBS = B.drop 9 line
return (Nothing, decodeBase16 hashBS)
Copy permalink