MapGuide RFC 145 - MapGuide Repository Re-organization

This page contains a change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.

Status

RFC Template Version	(1.0)
Submission Date	25 Aug 2014
Last Modified
Author	Jackie Ng
RFC Status	superceded
Implementation Status	not started
Proposed Milestone	3.0
Assigned PSC guide(s)
Voting History
+1
+0
-0
-1
Abstained

This RFC has been superceded by MapGuide RFC 149

Overview

This RFC proposes to re-organize the MapGuide repository to improve efficiency of checkout and other repository-wide actions.

Motivation

MapGuide's repository is huge. The bulk of this size is due to also keeping the source code of all third-party libraries and components that MapGuide depends on as part of the source tree.

This makes initial check out and any repository-wide actions a very slow process. Checking out specific branches also wears the same performance penalty.

Proposed Solution

As part of MapGuide RFC 138, we parameterized the build settings (via environment variables) of MapGuide components that depend on Apache httpd and PHP.

For this RFC, we will extend this approach to cover every referenced library/component under Oem. The setenvironment.bat, setenvironment64.bat and configure.in/Makefile.am files will do the necessary legwork to set these environment variables up.

Once this is done, the Oem directory under MgDev will be moved up a level to become a sibling directory of MgDev. The layout goes from this:

/trunk
    /Installer
    /MgDev
        /Oem

to this

/trunk
    /Installer
    /MgDev
    /Oem

The setenvironment.bat, setenvironment64.bat and configure.in scripts will now assume Oem is a sibling directory of MgDev and not a child one for all the environment variables it needs to set.

When it comes time to branch for specific releases, MgDev and Oem are branched individually. For example, a 3.0 release branch would look like this:

/branches
    /3.0
        /Installer [branched from trunk/Installer]
        /MgDev [branched from trunk/MgDev]
        /Oem [branched from trunk/Oem]

This repository layout offers the following benefits:

• MgDev checkout is substantially faster.
• Oem checkout can be a one-time event. Targeting specific-branches is a simple case of making a physical copy of the Oem working copy and svn switching to the branch-specific Oem.
• Oem component updates happen independently of the MapGuide source.
• On Linux, this will greatly improve our ability to build MapGuide against system-installed versions of various Oem components as this setup gives us greater freedom to cherry-pick what components will link against system-installed libraries and which ones will link against internal Oem copies.

Implications

This repository change will impact on how developers set up their working copies and/or automated build systems. Instead of just checking out MgDev. They have to checkout both MgDev and Oem and have Oem be a sibling of MgDev in their working copy directory structure in order for the environment setup scripts to work under their default settings.

This repository structure change will mean that running setenvironment.bat/setenvironment64.bat before launching Visual Studio to build MapGuide is now mandatory. Previously, the Server solution could be built and run from Visual Studio without having to call setenvironment.bat as none of its projects had parameterized include/linker paths. With this change, this will no longer be the case. "headless" builds via build.bat will still operate as before.

There will be a short momentary disruption while the implementation of this RFC is carried out. Since we are not currently in a stage of putting out a new release, the impact of this disruption should be minimal. Developers with existing trunk working copies will need to checkout Oem individually once this RFC is carried out and have it sit alongside MgDev in order for environment setup scripts to work under their default settings.

Test Plan

Build/Run on Windows/Linux. Ensure build system can work under the new repo layout and that the existing unit test suite passes.

Funding/Resources

Community