General structure and naming
Gitolite allows us to arrange repositories in folders. Here's some of the most common folders we use:
modules/: all open-source modules will be under
forge/: well, Forge modules will be hosted here.
enterprise/: Enterprise Edition modules and bundles.
internal/: Internal projects.
sys/: Internal systems tools. Some or all of those might be open-sourced at some point.
training/: All code base for training exercises
user/: Users are able to create their own repositories if needed. See Git usage#User repositories.
Since the main Magnolia CMS codebase doesn't really pertain in any of these folders, it sits at the top level:
magnolia_main.git. Note that this repository is mirrored into
magnolia_main.pub.git for public anonymous access.
Projects migrated from Subversion
Projects migrated from Subversion have been migrated as closely as possible; however, there are a few caveats to be aware of:
- Empty directories: Git doesn't track directories. The usual technique in Git, to have an empty directory in the repository, is to add a placeholder file in it (
README.txtexplaining the purpose of the directory could be considered a good practice, if that directory was really necessary). For the most part, empty directories in our Subversion projects were not necessary, and haven't been migrated.
There is however an *exception": the main projec.t For this project we manually (well, using a script) recreated the empty directories for all existing branches, and added a file called
.emptydir-placeholder. If you get to work on the project, please go ahead and do
find . -name .emptydir-placeholder; i'm pretty sure most of these files are unnecessary, but some are. Ideally, someone should go ahead and 1) remove the unnecessary ones, 2) replace the necessary ones by a
README.txtthat explains the purpose of the directory.
If you notice another project that had such a necessarily empty directory, feel free to recreate it; alternatively, check with me - we should be able to reuse the script I used for the main project.
Ignores: in Subversion, ignored files are tracked/marked in the
svn:ignoreproperty, at directory level. While migrating, we took advantage of Git's
.gitignoremechanism, which allows marking ignore files outside of their own directory. We converted every
svn:ignoreproperty into a single
.gitignorefile at the top of the repository. One of the first things one should do when taking over one of the migrated repositories, is to clean up that file. For instance,
could be advantageously replaced by
- Keyword expansion: we've never really used Subversion's keyword expansion consistently nor correctly. Files have been migrated as they were, and it being Git, those keyword should now simply be removed from our files.
- Repository size: Some repositories might be too big after migration. This is due to how Git works; if a repository (STK is an example) has, or had at some point in its history, large binary files, those are kept in the repository ~forever. There are a bunch of techniques to get around that, mostly based around the powerful
filter-branchfeature of Git. Contact one of the administrators before attempting to do, as it might break stuff pretty bad.
List of migrated projects
The Magnolia CMS codebase has been migrated from Subversion to Git. This page lists repositories which have been migrated and their status; some modules have been renamed or moved in the process, so this should help finding your way.
Previous location on SVN
Blossom extension data
Google Analytics module
Google Sitemap module
Public User Registration module
Standard Templating Kit
Standard Templating Kit Prototype
Not migrated yet
Advanced Cache module
Content Translation Support
Transactional Exchange module