Versioning file permissions in svn

Date

There can be cases when it's important to version file permissions. One case I have at hand is to have a cache directory for automatically generated images in a web application. The cache must be open for writing by the webserver, because the images are generated via a PHP script.

Unfortunately, subversion does not perform versioning of the file permissions. As a result, when the cache directory is checked out, the permissions are restricted to the user who checks out, and the webserver cannot write content in the cache. There are some solutions to this problem:

  1. create a script that has to be run every time the tree is freshly checked out. The script checks the permission of critical directories and files, and put them correct. Advantages: quick to implement. Disadvantages: easy to forget, must be maintained for changes.
  2. Use the asvn wrapper to enhance subversion so that it can handle permissions via properties. Advantages: cleaner approach. Disadvantages: apparently none.
  3. Let the webserver user check out the tree. Advantages: conceptually simple. Disadvantages: You have to have access to the webserver user, and if a security flaw is available, the webserver can potentially alter any file or write in any directory.

I'm sure there are other solutions, but I'm not aware of them at the moment. My personal choice is for the first solution, mainly because I don't want to bring asvn into the system right now. The script scales appropriately for my current needs.


Global includes

Date

Sometimes in my programmer career I did this mistake: a big global header file that gets included by most, if not all the files in my project. This file normally contains one or more of the following: global variables, general defines or enums, other includes. I have also found this mistake in other's codes as well, when I had to maintain or change these codes.

The apparent advantages of this approach are:

  • You have a central, unique place where to look for global variables, and they are instantly accessible just by including the this header file.
  • You save typing, because by having global.h include other files, you save the need to specify these files explicitly every time.
  • You have application-wide settings clearly partitioned and accessible.

The main reasons why I consider this practice a mistake are three. First of all, with a global include file, all the files in the project gain a dependency toward this file. This dependency is related only to the layout of the code, not on the conceptual entities you are working with and how they interact in your design. If the language is compiled, this potentially leads to an application-wide recompile when the global.h is changed, even for those files that are not actively dependent on the part that changed. If the language is interpreted, you slow down the execution because you are potentially parsing sections of the code that are not used for the invoked task.

The second problem is that if you are using the global include to further include other headers, so to make your typing life easier (by including all of them with a single #include <global.h>), you are effectively making your future maintainer life more difficult: you lose information about what is really used by the code and what is not. Compare for example:

globals.h:

#include <foo.h>
#include <bar.h>
#include <baz.h>

file.c:

#include <global.h>

<other code using only foo.h>

With the more communicative

file.c:

#include <foo.h>

<other code using only foo.h>

In the second example, bar.h and baz.h are not included. This explicitly states to a maintainer that file.c only uses foo.h, an information that was more complex to devise in the first example, in particular if the code is complex and no namespacing is used. This highly simplifies many refactorings and code auditing.

Finally, the global file tends to become a catch-all for the bad practice of global variables, mainly with the justification of keeping consistency. Instead, the file keeps becoming more complex and difficult to maintain as many conceptually unrelated entities are aggregated.

A situation where a global include is instead useful is when you develop a library. The global include makes the library interface available. This is fine, because in general a library user needs to import the interface as a whole, or eventually a conceptually whole subpart of it. Check out, for example, #include <gl/gl.h> and #include <gl/glut.h> in openGL.

References:


Welcome!

Date

A warm welcome to anyone browsing this website.

The idea of this site came to me when I decided to write down many experiences I had in science. Many sources are available for science, the most notable probably being Wikipedia, and I'm not really trying to fill a gap. Most of the information you will find here come either from some other website, or some other knowledge repository (books, articles, and so on) or from my personal experience.

As a programmer, I will also write down ideas relative to programming applied to science, coding ideas and design, but also GUI usability, tips and tricks and so on. I will provide downloads of my own code snippets, when possible.

Of course, everything depends on my spare time, which is, quite expectedly, not really much. I will do as much as I can, mainly because I like the idea of a website "for the science".