semi-atomic-update
Mon Jun 22 08:24:49 2009
In the past, as the post-commit process processed all the changes to the repository, it would go ahead and update the files in the web tree one by one. If the update took long (or had bugs that caused it to abort the operation after updating some files), artifacts could be seen as the web tree was only partially updated.
This has been solved: the post-commit now generates temporary files as it goes and only when all the files have been successfully generated, it moves all of them into the right (visible) locations, almost all at once.
While the update is not atomic (and it is possible to implement a truly atomic update by the means of clever use of symlinks), I decided to stick with this algorithm since:
- It is very unlikely that the code will hit errors during the cycle that moves the temporary files to their right locations, as that exercises a very little portion of code. That means that the problem of crashes leaving the visible tree in an inconsistent state (which is a real problem in the case of the freaks-unidos wiki, which I always run in the latest development version) becomes extremely unlikely.
- The process of moving all these files should be very fast. Since most people interact with the web tree through a web browser, it is unlikely that making it truly atomic would bring any advantages. Files are loaded sequentially by a web browser, which negates any advantages of making the process truly atomic.
Discussionimage-has-prev-and-next-in-tag-links
Sat Jun 13 17:01:38 2009
If you load an image with a tag=foo in the query string where foo is one of the tags the image has, a link will be shown to the previous and next images that have the tag.
Of course, the links in the gallery for a given tag now include that in the query string.
This means that if you go to a given tag's gallery and start navigating from there, you'll be able to use the previous and next links to navigate the gallery.
location-tab
Sat Jun 13 17:01:38 2009
The googlemap extension now adds a 'Location' tab to pages that have a location associated with them. Clicking the tab just shows a map with a marker in the right location.
Better locking for the Sqlite3 DB
Wed Jun 10 10:41:20 2009
Previously, during most of an post-commit-hook update, the CGI program would just stall, waiting to get a lock on the Sqlite3 DB. While most updates would take less than a minute, this was specially problematic with long updates (such as “regenerate everything”, which in large wikis can take hours).
Well, I've spent some hours looking at the File Locking and Concurrency in SQLite v3 document and debugging the code and managed to fix this. The problem was rather complex, with the following problematic interaction:
- post-commit-hook starts.
- CGI process starts running a query.
- post-commit-hook tries to perform a query that modifies the database.
- Query from the post-commit-hook fails, with “Database is locked” error.
- post-commit-hook decides to sleep and try again in a few seconds.
- CGI process finishes its query.
- post-commit-hook restarts its query and this time it succeeds. Continues.
At this point, any accesses from CGI processes get blocked with “Database is locked” errors until the post-commit-hook terminates. It turned out that the post-commit-hook was leaking a SQLite prepared-statement in step 4. Accesses from other processes had to wait until all prepared-statements that modify the database from the post-commit-hook had been finalized, which would only happen when the process terminated.
This was fixed in r15631.
Maps for tags
Sun Jun 7 16:41:14 2009
If a tag has files that have a location set, a third view (in addition to the list of files and the image-oriented view) is generated with a map with markers for every file. You can click the markers to get to the associated files.
You can see an example here:
There is, however, a small problem. Google Maps' API only seems to work from pages served with MIME type text/html. However, for the tags page, we need to be able to serve them with MIME type application/xhtml+xml, so that we can load them with AJAX and extract information from their DOM.
Also, if you do:
alert('&')You'll get just '&' or '&', depending on whether your page is text/html or application/xhtml+xml. Ugh.
I guess I'll workaround this eventually.
Set image size through query string
Sun Jun 7 00:59:51 2009
In the URL for the page for a given image (a file handled by the image extension), you can specify the desired size for the picture by adding a 'size' parameter to the query string with a number as its value. This will cause the largest version such that its width and height are less than or equal to the number specified to be used.
Weblog extension listing top posts
Sat Jun 6 17:38:06 2009
The weblogs extension provides a “weblogabout” tag, meant to be included in the ToC file. This is expanded to some information about the weblog. I've maded it possible for extensions to add information to the expansion of this tag. For example, the email extension will provide links for subscribing to a given article. Two interesting additions were made in the discuss and in the rating extensions: now weblogs provide a list of the highest rated and most commented posts.
See an example here (grep for "The following are the"):
Set the googlemap location with a clickable map
Sat Jun 6 17:31:58 2009
The metadata extension was improved to allow other extensions to define new ways of setting the values of properties (previously, the only supported types where «text», which just provides an text input field, and «select», which provides a drop down list with options). Then the Googlemap extension was improved to make it possible to set the location of a page (properties "svnwiki:location:longitude" and "svnwiki:location:latitude") by clicking on a map.
You can see an example here (grep for "Location"):
- http://wiki.freaks-unidos.net/cgi-bin/svnwiki/default//weblogs/azul/lines-around-the-ill?action=edit
edit-raw-files
Sat Jun 6 14:47:47 2009
When editing files, the Edit form will let you edit their content only if:
- They are normal wiki files (ie. not raw files).
- Their MIME type has the form 'text/*'.
This means that if you click the 'Edit' link in an image, the resulting for won't stupidly include the bytes of the image and ask you to modify them. However, if you try to modify, say, a CSS file, you'll still be able to edit it.
mail-includes-username
Mon May 18 19:24:01 2009
When a commit is made by an authenticated user, any resulting notifications will now include the username.
Last update: 2007-06-28 (Rev 11840)