I am trying to introduce Subversion(version control) in my company so I was doing some research on that, the first thing which really bothered me was the way the Subversion merges the changes in the IS because unlike many version control systems Subversion doesn’t use a “lock-modify-unlock” approach rather it uses a “copy-modify-merge” approach. Offcourse there is an option of locking the file and then doing some changes which protects that file to be changed…but then again that kills the purpose of Subversion because we wanted to use a version control where more than one person can work of the file at a time.
My question is we can’t take the approach of “copy-modify-merge” because unlike other languages webMethods coding isn’t in the text format where two people can make changes in the same file at a time and submit that file to Subversion and Subversion detects those changes automatically and merge those two files. So is anybody using the Subversion as their version control and if yes then what kind of approach they are using.
P.S : I am planning to use the Subversion with webMethods Deployer.
We would like to, since our company uses SV for other applications, but we would have to write a completely custom interface and/or a lot of manual steps. It doesn’t appear that wm is going to make this part of the WmVcs package in the foreseeable future, either.
You are right Roger…I would like to have comments about this from RMG,Mark and Rob …what do u guys think, I mean how should I go with that approach of subversion since you guys have a really good experince these stuff…
These two items tend to work against each other. This is why I usually follow these guidelines for version control (when a VCS is actually used, which interestingly for the projects I’ve been with has been relatively rare):
If at all possible, never have more than one person working on a package at the same time. Usually when the desire to do this occurs, it is because the package has too many things in it.
Manage at the package level, never the service level.
IS packages do not lend themselves to being “merge” managed. Don’t even try.
Use the package version number to tie to the VCS version.
Currently we are using CVS Filesafe with webMethods Deployer,but i dont have much comments to say about SubVersion etc…We do manage deployment at package and services level…Really i was not involved in configuration level to say much. so other experts (Rob/Mark/Jim/Castropb…) will have to chim in on this item.
always use version control, so it is easy to check what you have changed and to rollback to good version
always be able to see what has changed between versions to better understand the problems arising, i.e. reading the diffs of flow.xml, as well as checking differences in node.ndf files
build simple public methods for everyone to use them. Have someone responsible for that package, but allow everyone to submit work to it
always remeber to do unit tests for your code, instead of manually testing
OK, so since you always use version control, what level of granularity do you use (package or element)? What version control software do you use most frequently?
[INDENT]If you are working with IS-only components, I suggest that you use element/service/component level granularity.
[/INDENT]
I had done that extensively in the past (using PVCS) with great success.
The reason I prefer component level granularity is because its better option of the two.
More Detailed
Greater Flexibility
Better control over the process
At package level, you loose control over modifications (which is what you want to achieve in first place with source control). You dont want your developers sneaking other changes in the same package into production with unrelated service request/modification request.
But if you are looking for a simplified solution, ease-of-use and (more of) code repository, package level granularity is the right solution for you.
Please go through various post in wMUsers or through the Developer’s guide to understand which components to include in source control.
We use element granularity. It makes a problem when playing with java services, but on the other hand - gaves a lot of information. Esp. when you need to know, what was the modification, that someone did to that service a year ago. And why he did that…
Presently we use CVS (the cvsnt flavour, to have better access control) - and we are quite happy. After 1.5year the repository have about 6GB, wheras the full checkout of packages, less than 150MB. There are a lot of performance problems, but Subversion was far away after CVS. Not even talking about BitKeeper, which was simply unusable. Still I haven’t found a decent VCS tool for webMethods…
We start using subversion and works bad, we removed because is causing problems during deployment.
Add a loot of extra files in packages structures. Packages are growing rapidly e received 500 megabytes source code after introduction of subversion.
Because code size is large, deployment is hard, because transferring 500 megabytes via standard tools like deployer and even activating is costing much more time.
It is not possible if you do not change WM package loader, because loader is bored from those extra files. Bad.
We stop using it at this point, because is causing only troubles. But I am thing for solution like this:
Make export of the code on regular interval. Half a day for example, depends from you needs.
Use checksum utilities to check which files are changed, and sore this data together with exported packages. These activates can easily be automated.
