[darcs-users] moin to gitit migration

[Gwern Branwen]

On Mon, Apr 13, 2009 at 1:05 PM, Eric Kow <kowey at darcs.net> wrote:
> On Mon, Apr 13, 2009 at 12:40:32 -0400, Gwern Branwen wrote:
>> Yes, that looks like the compression bug. The easy diagnosis is
>> whether 'curl' fails and 'curl --compressed' succeeds.
>
> I can confirm with this diagnosis as well.
>
>> Supposedly, it's fixed in happstack-server darcs:
>> http://groups.google.com.gi/group/HAppS/browse_thread/thread/419a012cdc60cd47
>>
>> But as I comment in a gitit-devel thread, I rebuilt from darcs
>> everything, and the compressed issue didn't seem to go away.
>
> Another issue we have is performance.  Loading http://test.darcs.net
> seems to take about 15s wall time for me.  Ian has helped us to figure
> out what's going on and after some silly ps-usage on my part, we've
> worked out that one thing it seems to be doing is
>
>  darcs changes --xml-output --summary FrontPage.page
>
> which took 3 seconds wall time on test.darcs.net
>
> I suppose this is something that will be helped with the new filecache
> feature that Benedikt's been working on.  But otherwise, why is it
> doing that?  Is it possible to have an overview of what happens
> darcs-wise when we call up a page in gitit?

The key code is Darcs.hs in filestore. If you look, only two commands call --xml-output --summary, darcsLatestRevId and another; as it happens, all calls to those 2 in Gitit.hs couldn't possibly be the result of just viewing Front Page.page.
But viewing Front Page.page does call 'retrieve', alias for 'darcsRetrieve' - and it calls it without a version ID (with Nothing). The definition of darcsRetrieve says:

darcsRetrieve repo name Nothing =
  darcsLatestRevId repo name >>= darcsRetrieve repo name . Just

Oops. So a patch looks like this:

hunk ./Data/FileStore/Darcs.hs 259
-darcsRetrieve repo name Nothing =
-  darcsLatestRevId repo name >>= darcsRetrieve repo name . Just
+darcsRetrieve repo name Nothing = do (status, err, output) <- runDarcsCommand repo "query" ["contents", name]
+                                     if status == ExitSuccess
+                                      then return $ fromByteString output
+                                      else throwIO $ UnknownError $ "Error in darcs query contents:\n" ++ err

This should work as far as efficiency & avoiding calling darcs changes go; however, it breaks an invariant in filestore! The tests believe that calling 'retrieve' on a directory should be an error; but 'darcs query contents' on a directory quietly returns successfully with the empty string.

I would test this in my local gitit installation, but HEAD gitit seems to be borked: even if I use the default.conf straight from gitit/data in a empty directory, it crashes on me (even --help crashes!) with the error message:

gitit: (NoOption "default-page-type","get (DEFAULT/default-page-type)")

-- 
gwern
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 270 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090413/bffb2270/attachment.pgp>