Step by Step webMethods subversion Integration

Versions:

webMethods: 8.2

Subversion Server 1.6.x

Subversion Clinets: Collabnet 1.6(command line), Tortoise SVN 1.6/1.7

 

1)   TortoiseSVN-1.7.11.23600-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:

[general]

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

Add: watt.server.createPackage.ignorePattern=.svn

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

replaces it.

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.

 

 

Normal 0 false false false EN-US X-NONE X-NONE

Basic SVN Commands:

SVN Import:

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

 

 

 

Normal 0 false false false EN-US X-NONE X-NONE

% 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

files.

% 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"

depend= Tcpip

start= auto

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"

depend= Tcpip

start= auto

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

http://localhost/svn/webMethods_SVN/packages/Default/ns/Untitled/test/flow.xml

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”