I am looking into setting up Version control on Local Service Development. The SAG documentation from Service_Development_Help is a very good starting point, however, there are items that I would like to clarify (this setup is for webMethods 9.7):
Is there a tight dependency between Eclipse plugin version to use and webMethods version? In the document for Polarion plugin is mentioned to use the connector version 3.0.x. The connector version is leading the Plugin version as well, furthermore, also the minimum version of the SVN server.
In other words, I would like to know if it’s advisable to use the latest Polarion plugin + connector and latest support SVN on webMethods 9.7 or this might lead to further issues?
How is the wiring between the assets on the SVN repo and the ones in the local workspace done? Normally, I would see the hidden .svn folders that are used for tracing the differences/status between checkedout assets and the ones on the repository. These files are not present here, but I see that the .project file at the package level (same level with the manifest file) contains:
“
com.softwareag.is.vcsintegration.nature
”
This could probably be related to keeping the link between the working copy and the SVN, but I am not sure.
Did you face any issues with lock-unlock on server level?
Can you configure at the client level (Designer) automatic update of the working copy after commit/check-out?
I think there is no dependency, we use different SVN-Tools for our local service dev. We use Subclipse in the Designer and Tortoise SVN as Explorer integration in Windows.
no there are not keeping the link between svn and the working copy.
I’ve checked my packages folder in the IS on my local workstation and there is a hidden .svn Folder with the informations about linking the workstation copy to svn.
On local workstation dev. you don’t lock the services. So we don’t have any Problems here.
On our old env. central dev. on one server we also don’t have problems with lockings. Only Java-Services on the same folder all getting locked if you lock one of them…
as far as i know, this isn’t possible. We have to do some manual steps like updating our workstations every day after start-up and do a package reload to get all the changes. We also hope that there is a way to automate this step.
After further investigation, I got my answer to some of the questions I mentioned in this post. I will check further items 2, 3 (see below):
Polarion Software Subversive SVN plug-in and connector 3.0.x - whether we are bound to use these versions only, together with SVN 1.7.x or not.
I checked the documentation from webm95, 96 and 97 and I see that the Supported Platforms and Eclipse Plugins are the same (in terms of versioning); there is one difference, starting with webm96, SoftwareAG offer support for Git as well.
Support SoftwareAG mentioned that the supported versions mentioned in the documentation are the ones tested. If we decide to go for newer versions, they will support us in troubleshooting any issues that we might face.
Moreover, it’s not recommended to use an SVN version lower than 1.7. It seems that there are some issues with loading webService connectors and descriptors from SVN 1.6 - this is also stated in the documentation.
We will also use Tortoise SVN since there are a couple of operations that cannot be done via Designer (are mentioned also in the documentation).
Wiring between the assets on SVN project from the repository and the ones in the local workspace
It seems that Subversion 1.7 offers a completely new approach to how working copy metadata (wiring info) is stored and maintained compared to the older versions: now each working copy has only one .svn subdirectory which is an immediate child of the root of the working copy; previously the .svn folders were present in each directory. => I will re-check probably the .svn folder is located only under the root working copy. @Michael: What SVN version are you using?
Lock-Unlock at server level
I will give more details here: when working with Local Service Development, there is a locking extended property on the IS that should be set to “system”.
It is recommended to avoid to merge changes on the webMethods assets since the SVN plugin is not SCM type and treats these as files only. Therefore, a workaround for this is for the developers to lock the asset from SVN (via the Designer SVN Plugin) before they start modifying it. This way, another developer will not be able to modify it in the same time and we avoid merging.
4. Can you configure at the client level (Designer) automatic update of the working copy after commit/check-out?
Indeed, a good workaround for this is to have a good procedure in place: update the working copy constantly and reload the package.
I think the update of the working copy could be done automatically in the end with scripts that execute the svn update command (maybe give as input the last revision number that was updated). Not sure however on the packages reload, in the end a restart of the Local IS would reload automatically all the packages.
Can you please provide further details on the reason why you have to do a package reload to get all the changes after startup of Designer? This step is required to solve what kind of issues?
After further investigation, I decided to look into Subclipse plugin as well (for an initial comparison with Subversive from Polarion).
Regardless of the plugin you use on top of Designer, you can configure an automatic refresh of your workspace that gets executed before you perform any VCS operatin (go to Preferences → General → Workspace for this). This will make sure that the workspace is synchronized with the underlying filesystem.
There’s also a warning thrown by the ID itself when I try to commit my changes from the working copy. See the attached screenshot for details.
