Step by Step webMethods subversion Integration
Subversion Server 1.6.x
Subversion Clinets: Collabnet 1.6(command line), Tortoise SVN 1.6/1.7
1) TortoiseSVN-220.127.116.1100-x64-svn-1.7.8 ) Download Tortoise SVN 64 bit client and install it on a remote system or on your Desktop.
2) Download subversion client CollabNetSubversion-client-1.6.20-1-Win32 from http://www.collab.net/downloads/subversion and install it on the same computer where your Integration Server(IS) is running. Subversion only supports 1.6.x versions.
3) SVN Client software must be executable by the user account that is used to start IS. So, make sure the user should have Admin access to the IS and also to the computer.
4) Include “C:Program Files:TortoiseSVNin” in the PATH statement for the user account.
5) Tortoise SVN is a Shell extension to use the client we should always open it in a Repo Browser, Select a folder -> Right click on it -> Go to TortoiseSVN and click on Repo Browser.
6) Download Subversion server software CollabNetSubversion-server-1.6.20-1-Win32.exe from http://www.collab.net/downloads/subversion
7) Install the Subversion server software and access it via URL http://localhost/svn/
8) Start/Stop or restart the Subversion Server via the windows service "Collabnet Subversion Apache "
9) Browse Repositories and click on Create button to create one “webMethods_SVN”
10) This Repository will be by default created at C:csvndata:repositories and you can also access your Repository via http://localhost/svn/webMethods_SVN/
Asks for Authentication, provide default username and pwd…”admin”
For command line use $svn create webMethods_SVN --username=<> --password=<>
11) Go to Repositories access rules and grant “rw” access to SVN users
EX: admin = rw
Go to C:csvndata:repositories:webMethods_SVN:config and open svnserve.conf and uncomment the lines and save the changes:
anon-access = read
auth-access = write
password-db = passwd
12) Open the file password located at webMethods_SVN repository and add Integration Server and SVN Server users and save the file
Administrator = manage
admin = admin
Start the Repository using svnserve command
$svnserve -d -r C:csvn:data:repositories
13) Now you can access all the Repositories from svn://localhost
14) In Repo Browser access your Repository via svn://localhost
At this moment Authentication dialog might pop out. use your SVN user account to get into the repository. Please keep “Save authentication” option unchecked. Otherwise all changes to SVN are logged under one account.
15) Go to webMethods_SVN Repository create a folder test1/packages via add folder option
16) Do a SVN Commit to commit your changes to SVN Server and then Do SVN Update to synchronize your working directory with the repository content.
17) Now since your changes were committed at SVN server you now have to map SVN link to IS packages folder...see screenshot at the end
18) Open IS Admin console and Do the below settings at Settings -> extended settings
So, everytime when you do a chekin to your repository, your working directory which is IS/packages will exclude .svn files while placing them in a repository
Remove watt.server.ns.backupNodes Setting
19) If you have enabled the watt.server.ns.backupNodes setting, you must remove it. This
setting conflicts with the operation of the VCS Integration feature, which essentially
To remove the watt.server.ns.backupNodes setting
1 In the Integration Server Administrator, go to the Settings > Extended page.
2 Determine whether the watt.server.ns.backupNodes setting is displayed in the
Extended Settings list. If it is, go to step 4. If the setting is not visible:
a Click Show and Hide Keys.
b On the Settings > Extended > Show and Hide Keys page, look for the setting
watt.server.ns.backupNodes. If the setting is present, select the check box next to
watt.server.ns.backupNodes and click Save Changes. If the setting is not visible,
click Return to Extended Settings.
3 On the Settings > Extended page, click Edit Extended Settings.
4 In the Extended Settings text box, delete the watt.server.ns.backupNodes setting.
5. Click Save Changes.
20) Settings at Developer
1. Start Developer.
2. On the Tools menu, click Options, and then click General.
3. Under the Navigation panel, clear the Automatically unlock upon save check box, and then click OK.
21) Settings at Designer
1) Start Designer.
2 ) Go to Windows > Preferences > Software AG > Service Development > Package Navigator.
3 Clear the Automatically unlock upon save check box, and then click OK.
21) To configure the WmVCS package to work with Subversion
1 In Integration Server Administrator, go to the Solutions > VCS > Edit Configuration page.
2 In the Select Version Control System list, click Subversion, and then click Save Changes.
3 Restart Integration Server.
To map one Integration Server user to one VCS user
1 In the Integration Server Administrator, go to the Solutions > VCS > User Mapping >
Create New User Mapping page.
2 In the Integration Server User Name field, type the Integration Server user name and the VCS user name and password. Use the format Integration Server user name;VCS user
name;VCS password. Type the entry for each Integration Server user on its own line.
All user account credentials are case-sensitive.
Note: If you specify an invalid VCS user name and password, when commands are sent to the VCS client, the client will stop responding while awaiting the correct user name and password. As a result, Developer or Designer will also stop responding. Integration Server Administrator does not validate, create, or modify VCS users.
3 Click Save Changes.
The VCS Integration feature encrypts the VCS passwords and stores the VCS user names and encrypted passwords on Integration Server.
-> Your Repository should have the folder packages in it. Since your working directory would be IS/packages, Subversion expects a “packages” folder in your repository.
Error: svn://localhost/packages, D:webMethods82IntegrationServerpackages]; exit value: 1; output: [svn: E170000: URL 'svn://localhost/packages' doesn't exist]
Go to your repository svn://localhost/ and create a folder and specify the SVN URL accordingly.
For Example: If you are creating svn://localhost/packages then your SVN URL should be svn://localhost/ and if you are creating /wM/packages then your SVN URL should be svn://localhost/wM/packages
Connecting to Subversion for the First Time
1 Go to the Solutions > VCS > Edit Configuration page and click the Advanced Settings link.
2 In the Subversion Repository Location field, type the URL for the Subversion repository.
3 Click Save Changes.
4 Restart Integration Server.
Re-Connecting to Subversion or changing the IP or Deleting:
Check the optionfirst whenever you delete the existing URL
Now your working copy or Directory /IS/Packages is subversioned.
Basic SVN Commands:
To set an IS, one must first do the initial import in Subversion. This must be done prior to running the WmSubversion package and if you were not able to establish a svnlink from IS Admin console. To import IS into Subversion, run the following commands. (Note that path names and comments are more brief than in most environments.)
% cd D:webMethods82IntegrationServerpackages
% svn import -m "Initial import." . http://localhost/svn/webMethods_SVN/test1/packages --username=admin --password=admin
Note that because by default Subversion will import all files, one might first want to remove files that are generated, such as .bak, .class and node.ndf
% cd ..
% mv packages D:/archive
svn checkout http://localhost/svn/webMethods_SVN/test1/packages --username=admin --password=admin packages
The subversion server can now be started using the command svnserve -D -r -R /home/user/myrepo/ (this runs on port 631).
Since this command needs to be executed every time the system reboots, the user may use the system init scripts.
Many linux distributions (like SuSE), which ship with svnserve provide the init script in /etc/init.d/.
In this case the server can be started using (after modifying them to adjust the repository path):
svnserve as daemon:
The easiest option is to run svnserve as a standalone “daemon” process. Use the -d option for this:
$ svnserve -d
$ # svnserve is now running, listening on port 3690
When running svnserve in daemon mode, you can use the --listen-port and --listen-host options to customize the exact port and hostname to “bind” to. Once we successfully start svnserve as explained previously, it makes every repository on your system available to the network.
A client needs to specify an absolute path in the repository URL. For example, if a repository is located at /var/svn/project1, a client would reach it via svn://host.example.com/var/svn/project1. To increase security, you can pass the -r option to svnserve, which restricts it to exporting only repositories below that path. For example:
$ svnserve -d -r /var/svn
Using the -r option effectively modifies the location that the program treats as the root of the remote filesystem space.
To start SVN Repository
C:\svnserve -d –r C:\csvn\data\repositories\\
Via Repo browser, we can access through svn://localhost/
Where svn://localhost would be the root for C:\csvn\data\repositories\\
Clients then use URLs that have that path portion removed from them, leaving much shorter (and much less revealing) URLs:
$ svn checkout svn://host.example.com/project1
svnserve as a Windows service:
If your Windows system is a descendant of Windows NT (Windows 2000 or newer), you can run svnserve as a standard Windows service.
This is typically a much nicer experience than running it as a standalone daemon with the --daemon (-d) option. Using daemon mode requires launching a console, typing a command, and then leaving the console window running indefinitely. A Windows service, however, runs in the background, can start at boot time automatically, and can be started and stopped using the same consistent administration interface as other Windows services.
You'll need to define the new service using the command-line tool SC.EXE. Much like the inetd configuration line, you must specify an exact invocation of svnserve for Windows to run at startup time:
C:\> sc create svn
binpath= "C:\svn\bin\svnserve.exe --service -r C:\repos"
displayname= "Subversion Server"
This defines a new Windows service named svn which executes a particular svnserve.exe command when started (in this case, rooted at C:\repos). There are a number of caveats in the prior example, however.
First, notice that the svnserve.exe program must always be invoked with the --service option.
Any other options to svnserve must then be specified on the same line, but you cannot add conflicting options such as --daemon (-d), --tunnel,
or --inetd (-i). Options such as -r or --listen-port are fine, though.
Second, be careful about spaces when invoking the SC.EXE command: the key= value patterns must have no spaces between key= and must have exactly one space before the value. Lastly, be careful about spaces in your command line to be invoked. If a directory name contains spaces (or other characters that need escaping), place the entire inner value of binpath in double quotes, by escaping them:
C:\> sc create svn
binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r C:\repos"
displayname= "Subversion Server"
Also note that the word binpath is misleading—its value is a command line, not the path to an executable.
That's why you need to surround it with quotes if it contains embedded spaces.
Once the service is defined, it can be stopped, started, or queried using standard GUI tools (the Services administrative control panel), or at the command line:
C:\> net stop svn
C:\> net start svn
The service can also be uninstalled (i.e., undefined) by deleting its definition: sc delete svn. Just be sure to stop the service first! The SC.EXE program has many other subcommands and options; run sc /? to learn more about it.
svn unlock --force
Do not use IS Admin console to unlock the elements used by VCS feature. If the lock status of an element is not correct then If these conditions occur, refresh the Developer Navigation panel. If the condition persists, apply the Check In command. If you are still having problems, check in theelement with the VCS client and restart the Integration Server.
svn resolve --accept working “working copy/filename”