WFA doesnt have a native source control mechanism. But as sinha and abhit has explained, it does provide hooks to do that.
This is how, many WFA customers today manage and source control the workflows.
Have 3 WFA servers
- Development Server- This is the server where the actual wokflow development command development etc happens (This is a sandbox enviroment typically)
- Test Server- This is the server that exactly mimics the product server with exact OCUM datasources, controllers etc
- Production Server - This is the server on which the workflow gets invoked and executed.(Worfkow gets prometd from test to prodcution)
Do all your workflow development in Development server once its good enough with WF development and testing move to Test Server by exporting as dar file. Run couple of more test on the test server. If everything is satisfactory move to Produciton Server.
As you do your development in server 1, keep checking in the command scripts into SVN,CVS etc as .ps1 and .txt files for sql finders, filters and userinput query.
And once the workflow is in a decent shape checkin the .dar file as well.
The reason to checkin both the .ps1 file and .dar file is because the workflow also contains variable, mvel expressions etc which is not captured in the .ps1 file.
This way you can have a source control system, with WFA.
Make use of the version for individual commands and the description fields as comments for the changes as well.
I have seen quite a few workflow developers making use of the description fields of commads,workflows as comment field as well apart from description of the workflow or command.
Hope this helps. Not the easiest or the simple solution. But it does help to keep version control and source control.
PS: Lock all the commands, finders, filters and workflow in your development enviroment right before you move it to test.