Managing ABAP Source Code in Source Control

I'm interested as to what the benefit is of version control outside the ABAP stack of the SAP system.

I've never seen anyone use external source code control for ABAP, as it's built right in. I've never seen anyone code ABAP outside the SAP system either. It really doesn't fit the model.

SAP's ABAP stack is a single-development system environment. All the developers log on to the one system and develop there. The system records versions automatically, and groups changed objects into transports. A transport is just a list of changed objects. Once you export the transport, the version numbers are incremented for each object and you get the package for the other systems.

The ABAP stack also doesn't really have a "build" concept as such. Everything you do is a patch.


I used SAPLINK (mentioned in previous answer) for that purpose. There is also a related project called "zake", that supposedly can automate some of the tasks but I never used it. I simply exported my code manually to so-called slinkees (they contain single objects like function groups; nuggets on the other hand contain several objects).

Reasons to use some external source control system:

  • correlation to non-abap source code (as our software consisted of .net and abap code)
  • hosting / maintaining SAP was not something we were exactly good at, so it was good to know you had your code in a safe place

one thing though: you need at least WAS 620 in order to use saplink

Tags:

Abap

Sap Basis