We are migrating from 7.1.2 to 8.2.2. In 7.1.2, we use Subversion and Developer – but it does not work as described by all (or maybe I am not understanding what I am reading).
Basically, we are a shared development shop; In 7.1.2, once we create a package in Developer, it does not appear in Developer unless we go to the Subversion server and check the package and structure into SVN. Then, we check that same package out into our local file system and activate the package on the IS, and we are able to develop / change etc. Check in/out works from within Developer correctly at this point.
In order to use SVN correctly, each integration server user is mapped to the same VCS user name.
In 8.2.2, we have followed SAG instructions for shared development, but we are still experiencing the issue in Designer where:
Initially creating a package yields a service exception
The package is not immediately visible in Designer; we must follow the same steps (like we did in 7.1.2) on the file system / SVN to make the package workable.
Check in/out works correctly at this point.
We don’t believe that this is sustainable.
We have made SVN integration / package creation / development work seamlessly with a local integration server versus a shared / remote integration server. Unfortunately, we cannot efficiently work with local integration servers available for each developer.
The current thought is to create package structures locally and then sync these remotely to SVN, but there doesn’t seem to be a way to make this work with the SAG plugins made available to Eclipse/Designer. Meaning, creating a package yields the file structure on the developer’s machine, and then check in/out happens at the file system level.
Any thoughts and ideas are welcome. Please help!!!
I would recommend abandoning the use of the VCS integration feature. There are issues to overcome (as you’ve encountered) and it doesn’t provide the level of functionality that most expect from a versioning system.
As mentioned in the other thread, I’d suggest rolling your own process. Checkin and out at the package level using the file system–store package zip files in SVN. Not ideal but workable.
Or investigate CrossVista. It’s functionality is more in line with what one typically expects from a VCS.
The solution is to look at CrossVista - it’s got a web based and now (in version 1.6) an IDE plugin to do source control/diffs etc. I wouldn’t bother with command line stuff or manual solutions - I’ve never seen them work real well (XML fundamentally doesn’t do well when you compare it)…
I also wouldn’t hold out hope waiting for Software AG to provide something - it’s been what - 10 years since webMethods was used in anger (maybe longer) and for the entire time the vendor (webMethods then Software AG) have talked about it.
It’s not going to be pleasant looking at the XML natively though…
But be warned - if you’re going to do upgrades of versions in webMethods - the flow xml changes a bit (nothing major, just new default values for some added attributes) - even in crossvista this creates quite a lot of noise (e.g. “wow - looks like everything changed” when it wasn’t actually changed, just new values added courtesy of a save in Designer).
We are encountering similar issue, when package/folder/services are created in developer or designer IDE, it doesnt appear immediately in package navigator, got to follow the steps as mentioned n j-b thread.
As stated in SAG guide, any element created should automatically check in to svn repository and appear in navigator, so my query is, does this functionality works as stated and if im missing any configuration in between? or does this never work on IS 8.2.2?
My experience has been, regardless of the documentation, that using subversion directly with developer / designer CAN work if your shop is willing to setup a shared environment where initial manual check-in / check-out is acceptable.
If you go this route, once setups of packages are done and the subsequent package filesystem is checked into subversion and checked out (after deleting from filesystem), this will work for you.
Be careful with your builds, however. We have experienced trouble building packages from subversion where the directory / folder names are too long for Deployer to handle, and is directly attributable to saving within subversion. YMMV.