[darcs-users] "Static Gitit" site.

[Gwern Branwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, Apr 20, 2009 at 9:12 PM, Trent W. Buck  wrote:
> On Mon, Apr 20, 2009 at 08:49:12PM -0400, Gwern Branwen wrote:
>> On Mon, Apr 20, 2009 at 8:39 PM, Trent W. Buck  wrote:
>> > Daniel Carrera  writes:
>> >
>> >> Eric Kow wrote:
>> >>> I think we should give darcsit (*) a second chance.
>> >>
>> >> Ok. But I'll mention that OpenOffice has had exactly the same problem
>> >> for many years (but using CVS instead of Darcs) and they have never
>> >> found a solution to the speed problems other than to "staticize" the
>> >> website from time to time.
>> >>
>> >> My personal opinion is that running a website directly off of a SCM is
>> >> a mistake. But oh well.
>> >
>> > ikiwiki works by serving static pages.  The static pages are recompiled
>> > by a post-apply hook.  Thus, the cost of serving a page is low, but the
>> > cost of an edit is high (particularly since several index pages need to
>> > be recompiled).  I think browser-based editing is done by having a CGI
>> > script that edits the working tree and then does a commit.
>> >
>> > I get the impression that for every GET request, gitit
>> >
>> >    1. Asks Darcs when the source document was last changed.
>> >    2. If it is more recent than the cached HTML version,
>> >       recompiles the cached HTML version.
>> >    3. Serves the cached HTML version.
>> >
>> > I don't really see why this needs to be done for every READ, instead of
>> > for every WRITE.  It seems to me that reads are orders of magnitude more
>> > frequent than writes.
>>
>> Suppose someone pushed a bunch of patches. How would checking only on
>> writes through the web interface interact with that?
>
> I don't understand the question.  The model I describe has four components:
>
>  - a static httpd that serves the cached output real fast;
>  - a web editing interface, which results in a VCS commit;
>  - a VCS with a commit/apply hook; that calls
>  - the compiler, which created/updates the cached output.
>
> The compiler doesn't "see" any web interface at all.  It just sees
> changes to the VCS repository.

You weren't discussing your model when you asked that question. You
were discussing Gitit. If Gitit were to move to an ikiwiki-style of
things, then one could rely on an invariant and in such a hypothetical
Gitit there would be no need to check on reads.

But in Gitit as it actually exists, no such invariant exists, and
Gitit cannot assume that pushs or local records have not changed files
behind its back and thus caused its cached pages to be expired.

It's not obvious how to make Gitit work even if we went so far as to
mandate that there be post-record hooks (which we'd like not to do,
since one of the nice things about Gitit is working with unmodified
repos); perhaps Gitit could catch a SIGUSR which makes it dump
everything in the cache?

- --
gwern
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5)

iEYEAREKAAYFAkntIW8ACgkQvpDo5Pfl1oIOlACfUEaERDzvaI42lTDlWvdHKjkN
9HsAnil2ZCUfa6nyrIPNO8158kSF0Ua0
=dgPK
-----END PGP SIGNATURE-----