Subversion Control

On our radar

An eSpace Hub from which developers can check out their own version of the eSpace, develop and publish it locally, then merge it back to the central eSpace, and then merge that with a production eSpace.

We work in a traditional development environment.  Each developer has their own oml file that they run in their own eSpace, separate from other developers.

In addition, we have a development server, and then a production server.

Our subversion control process involves three steps.
  1. Developers develop their own extensions and OML files.
  2. All the Developers merge their extensions and OML files to a central development environment that has its own eSpace.
  3. The development eSpace is then published live.
This is the way development is traditionally done.  Why not have outsystmes create a way to have individual eSpaces that seamlessly integrates with a central eSpace through a subversion control process like tortoiseSVN or RedGates database Source control technology.  Then one can publish the central development eSpace to a production live environment.

This would be cool.  Currently we have to manually add and remove web methods and entities from our OML files as we merge them.  It is very tedious.

There are so many subversion control programs out there like VisualSVN, TortoiseSVN and RedGate Source Control, which we use for all our database changes.  Why should Outsystems be any different?
Created on 14 Apr 2011
Comments (1)
Version control is indeed one thing totally lacking in OAP, and causing many headaches when you have to maintain four servers each with different versions.

Note: it is called a "version control system", "subversion" is a specific one.