Version 39

    This wiki houses information regarding how to develop JBoss software with the subversion source control system


    Getting started with the JBoss SVN Repo


    We have migrated the JBossAS source base from CVS and moved it to a subversion repository.   The old CVS repo is still available in read only mode, all development should take place in subversion.


    The first thing you will need is a subversion client:

    1. TortoiseSVN -

    2. Subversion homepage -


    The repository location is:



    You can view this location in by entering the address in your web browser.

    You will be prompted for a login, use your username and password.


    Anonsvn is availabe at






    Examples of subversion tasks (command line usage):


    The subversion book is a great resource for your questions.  It details how to the various commands work.





    Subversion Migration FAQ

    1. I can't login or commit!

      1. You should be using your login.

      2. Ensure the correct username is being sent

        1. svn co --username YOURJBOSS.COMEMAIL https://blah........

      3. If you still cannot login, send your login and a description of your error to

      4. You can always reset your password on if you are unsure of it

        1. On click on "my account" from the member menu

        2. Click on "change your info"

        3. You can change your password from the following screen.  Please allow at least 10 minutes for the passwords to sync.

        4. Alternatively, you can go to and request a new password

    2. Why is subversion so slow on windows?

      1. This is due to the fact that windows sucks.  Here are some tips though:

    3. How do I undo a commit?


    From svn book:


    Another common use for svn merge is to roll back a change that has already been committed. Suppose you're working away happily on a working copy of /calc/trunk, and you discover that the change made way back in revision 303, which changed integer.c, is completely wrong. It never should have been committed. You can use svn merge to &147;undo&148; the change in your working copy, and then commit the local modification to the repository. All you need to do is to specify a reverse difference:


    svn merge -r 303:302


    U  integer.c


    svn status

    M  integer.c


      svn diff


      verify that the change is removed



    svn commit -m "Undoing change committed in r303."

    Sending        integer.c

    Transmitting file data .

    Committed revision 350.



    JavaEE5 TCK Work

    While the trunk is being migrated to the MC and VDF framework, it will be unstable. Work on TCK/CTS should be based on the branch with any changes merged to head. If the change is to a deployer that is in flux, create a jira issue with the svn patch set so it can be integrated latter. To checkout current stable jboss-head for JavaEE5 CTS, use:


    How do I move my project so subversion

    We have outlined the following procedure for moving a project to subversion

    1. Create a JIRA issue in the IT project which outlines the project to move and the timeframe which you will need it to be done

      1. You will need to also supply them with the repository name you would like to use

      2. This is crucial as you will need to cut off your cvs write access at a given time and instruct the developers to begin using subversion

    2. Send an announcment to jboss-development an announce your plans

    3. IT will take a cvs snapshot tarball, create a new subversion repository, and import the cvs tree into the new repository

      1. Once this is complete, you will be able to check out from subversion

      2. Check out your source, build it, and verify that things look as they should

    4. Remove the source from CVS and cut off the commit access


    How to test a subversion migration

    1. Log in to the QA lab

    2. export PATH=/opt/subversion/bin:/opt/cvs2svn-latest-eric:$PATH

    3. mkdir repotest

    4. copy the latest snapshot to your directory

    5. cp -r /homes/repos/cvs/jboss/project_to_extract .

    6. svnadmin create mytestrepo

    7. cvs2svn --dumpfile=cvsdumpfile --dump-only path_to_project_to_extract

      1. this will create a cvs dump file, make sure you are using the latest cvs2svn as a bug exists in older versions

    8. svnadmin load mytestrepo < cvsdumpfile



    Vendor Branch Guide

    Use Case

    A vendor branch refers to a source checkout of a thirdparty project which we would like to maintain in our own repository. We occasionally will temporarily fork a thirdparty dependency in order to apply a patch. An example of this would be a fork of apache-commons-logging which can be seen here. These projects will be integrated into JBossAS as binary dependencies.


    The current method of doing this is as follows. A developer upon discovering that a fork is needed would retrieve the thirdparty source and then simply add it to the top level of the JBoss CVS repository using the cvs import command. The developer would then make the appropriate changes and check in the code. A binary jar will be created and then placed in the JBoss http repository.


    The subversion method of doing this will be very similiar.


    A vendor directory will need to exist in our repository structure. This will be a one time creation which will contain all of our vendor source drops.


    Assuming our top level repository structure looks like this:



    The location of our vendor source drops would be:




    Let's walk through a real world example using apache-logging. What are the steps a developer would need to perform?


    1. Get the source of the project you wish to add as a vendor branch

      1. svn export apache-logging

      2. Note: if your 3rd party project uses cvs, you would use the cvs export command

    2. Import the source into our vendor repository.

      1. svn import /path/to/apache-logging

    -m 'importing initial vendor drop'

    1. We will need to place an initial tag on the source which we just imported. Remember that in Subversion a tag is essentially a copy of a source tree.

      1. $ svn copy

    -m 'tagging apache-logging with version 1.0'

    1. Now it is time to make your fix. Check out the source (import does not convert you local tree to a working copy)

      1. svn co apache-logging

    2. Make any necessary changes

    3. Build and test

    4. Commit your changes

      1. svn commit -m "bugfix"

    5. Tag your your work with appropriate tag in the methods described above




    Extraction of module from JBossAS source tree

    Use Case

    As subprojects mature they may reach the point where they become a standalone projects. Examples of this include webservices, ejb3, and jms. This section of the wiki is devoted to instructing a developer how to extract a module into it's own standalone entity.



    1. All source is currently in subversion



    1. Obtain agreement in the forums or on the jboss-development list that it is acceptable to extract module.

    2. Freeze development on the source for the module to be extracted

    3. Open a jira task in the IT project. The removal of a module and extraction to a new repository is an admin level operation.

    4. The steps involved for the IT group will be

      1. Creating a new subversion repository

      2. Performing a svnadmin dump using the a dumpfilter. This will essentially export the directory you are extracting with its history out of the repository.

      3. Performing a svnadmin load using the previously created dumpfilter

    5. At this point the new repository is setup and ready to use, the developer can check it out and resume development.

      1. A binary artifact(s) should be created and added to the http repository, this will be used to integrate in the overall jbossas build

    6. Cleanup of original module

      1. Remove the source from the original module using svn delete.

      2. Remove any references in the overall build system and replace with the thirdparty binary reference




    Service Patch Creation Guide

    Use Case

    This portion of the wiki describes the process for creating a service patch using subversion. For this exercise we will assume that a bug has been found by a customer in a legacy release (JBoss-4.0.3.SP1) and requires a patch. The procedure defined below will take a developer through the process of creating branch, making the necessary changes, and merging those changes into the main branch.


    # Branch from the release
    $ svn copy -m "Creating a branch for developing a patch"
    # Checkout the branch
    $ svn co jbas-1234_local_dir
    # Apply some changes, and commit
    $ svn commit -m "changes required for patch"


    At this point you may wish to port this patch to the current code line. To do this we will use the svn merge command. The svn merge command requires 3 pieces of information.


    1. An initial repository tree

    2. A final repository tree

    3. A working copy to apply the changes to


    Essentially, you are finding the change set between 1 & 2 and applying them to 3. In our case 1 would be the tagged JBoss-4.0.3.SP1 and 2 would be the JBoss-4.0.3.SP1.PATCH branch that you created. 3 would be the current 4.0 branch (which will you need to check out).


    Backporting procedure:

    # checkout a working copy of the 4.0 branch
    $ svn co jboss-4.0
    #apply the changeset between the 4.0.3.SP1 tagged release and your patched branch to your working copy
    $ svn merge jboss-4.0
    # The differences are now applied to your working copy. 
    # Ensure that no conflicts exist and then commit the work to current jboss-4.0 branch
    $ svn commit 


    SVN Administration


    There are 2 key administrative tasks which we handle, commit rights and cvs2svn migration testing.


    Commit rights in a svn repository

    This is pretty easy to administer.   First off, you will need project admin rights.  IT can grant this for you.  Once you have this for, for any repo just check out the admin folder.


    E.g.  svn co


    In that folder is a file called auth_conf, edit it, add usernames in the relevant location and commit your changes.




    As far as migration goes, see the above instructions, which will walk you through it.  The one point to note is that some projects required a "mutation" to change directory names.  We wrote some scripts to handle this.


    svn co

    cd scripts/cvs2svnmigration/mutation





    mutate is a directory which contains needed java classes for doing a mutation. is a script used to mutate jbossas. It's saved here for historical purposes. allows you to mutate a branch or tag from a given project.  It's documented in comments how to use.