Component based web project directory layout with git and symlinks

Question

I am planning my directory structure for a linux/apache/php web project like this:

Only www.example.com/webroot/ will be exposed in apache

www.example.com/
  webroot/
    index.php
    comp1/
    comp2/
  component/
    comp1/
      comp1.class.php
      comp1.js
    comp2/
      comp2.class.php
      comp2.css
  lib/
    lib1/
      lib1.class.php

the component/ and lib/ directory will only be in the php path.

To make the css and js files visible in the webroot directory I am planning to use symlinks.

  webroot/
    index.php
    comp1/
      comp1.js (symlinked)
    comp2/
      comp2.css (symlinked)

I tried following these principles:

• layout by components and libraries, not by file type and not by "public' or 'non public', index.php is an exception. This is for easier development.
• expose onle the minimal set of files in a public web directory and make everything else unaccesable to the web. Symlinking files that need to be public for the components and libs to a public location, but still mirroring the layout. So the component and library structure is also visible in the resulting html code in the links, which might help development.
• git usage should be safe and always work. it would be ok to follow some procedure to add a symlink to git, but after that checking them out or changing branches should be handled safely and clean

How will git handle the symlinking of the single files correctly, is there something to consider?

When it comes to images I will need to link directories, how to handle that with git?

  component/
    comp3/
      comp3.class.php
      img/
        img1.jpg
        img2.jpg
        img3.jpg

They should be linked here:

  webroot/
    comp3/
      img/ (symlinked ?)

If using symlinks for that has disadvantages maybe I could move images to the webroot/ tree directly, which would break the first principle for the third (git practicability).

So this is a git and symlink question. But I would be interested to hear comments about the php layout, maybe you want to use the comment function for this.

Canoe

Answer 1

As soon as you need to reuse some set of files elsewhere, that's when you should start thinking in term of components or (in git) submodules

Instead of managing webroot, and comp, and lib within the same repo (which is the SVN or the "Centralized way" for CVCS), you define:

• n repos, one per component you need to reuse (so 'img' would be a Git repo reused as a submodule within webroot, for instance)
• a main project for referencing the exact revision of those submodules you need.

That is one of advantages of submodules of symlink: you reference one exact revision, and if that component has some evolutions of its own, you don't see them immediately (not until you update your submodule anyway).
With a symlink, you see whatever state is the set of files at the other end of that link.

Caisson

Thank you for pointing this out. I had not thought of seeing the components as seperate projects. I will think about splitting off components at a later point, but for now I'll keep them together in one repository, which helps me keep it simple - karlthorwald - aka – Canoe

I am not sure but this solution does not take into account that one reason for the symlinking was to keep almost all of the files in an unexposed non public directory? I will make the question clearer now. - karlthorwald - aka – Canoe

@user89021: no problem: you can combine submodules with sylink (symlink to a submodule!). The key thing to note here is that Git is not meant to contain everything in one repo: https://mcmap.net/q/12446/-what-are-the-file-limits-in-git-number-and-size/… – Caisson

thank you. (please note that i am the OP as stackoverflow gives me different names) ok, i will think it over, but it does not really hit the core of my question – Canoe

your other post is quite interesting, also the linus quote. – Canoe