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:
TortoiseSVN - http://tortoisesvn.sourceforge.net/downloads
Subversion homepage - http://subversion.tigris.org
The repository location is: https://svn.jboss.org/repos/jbossas
You can view this location in by entering the address in your web browser.
You will be prompted for a login, use your jboss.com username and password.
Anonsvn is availabe at http://anonsvn.jboss.org/repos/jbossas
Examples of subversion tasks (command line usage):
Checkout jboss-head: svn co https://svn.jboss.org/repos/jbossas/trunk jboss-head
Checkout current stable jboss-head (for JavaEE5 CTS): svn co https://svn.jboss.org/repos/jbossas/branches/JEE5_TCK jboss-head
Checkout jboss-4.0.x: svn co https://svn.jboss.org/repos/jbossas/branches/Branch_4_0 jboss-4.0
Checkout tagged version jboss-4.0.3.SP1: svn co https://svn.jboss.org/repos/jbossas/tags/JBoss_4_0_3_SP1 jboss-4.0.3.SP1
Examine file history of server/build.xml in jboss-head: svn log https://svn.jboss.org/repos/jbossas/trunk/server/build.xml
The subversion book is a great resource for your questions. It details how to the various commands work.
http://svnbook.red-bean.com/nightly/en/svn-book.html
Subversion Migration FAQ
I can't login or commit!
You should be using your jboss.com login.
Ensure the correct username is being sent
svn co --username YOURJBOSS.COMEMAIL https://blah........
If you still cannot login, send your jboss.com login and a description of your error to labs-admin@jboss.com
You can always reset your password on jboss.com if you are unsure of it
On JBoss.com click on "my account" from the member menu
Click on "change your info"
You can change your password from the following screen. Please allow at least 10 minutes for the passwords to sync.
Alternatively, you can go to http://jboss.com/index.html?op=lostpassscreen&module=lostpassword and request a new password
Why is subversion so slow on windows?
This is due to the fact that windows sucks. Here are some tips though: http://wiki.jboss.org/wiki/Wiki.jsp?page=MakingSubversionMorePerformantOnWindows
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 http://svn.example.com/repos/calc/trunk
U integer.c
svn status
M integer.c
svn diff
&133;
verify that the change is removed
&133;
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 https://svn.jboss.org/repos/jbossas/branches/JEE5_TCK 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:
svn co https://svn.jboss.org/repos/jbossas/branches/JEE5_TCK jboss-head
How do I move my project so subversion
We have outlined the following procedure for moving a project to subversion
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
You will need to also supply them with the repository name you would like to use
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
Send an announcment to jboss-development an announce your plans
IT will take a cvs snapshot tarball, create a new subversion repository, and import the cvs tree into the new repository
Once this is complete, you will be able to check out from subversion
Check out your source, build it, and verify that things look as they should
Remove the source from CVS and cut off the commit access
How to test a subversion migration
Log in to the QA lab
export PATH=/opt/subversion/bin:/opt/cvs2svn-latest-eric:$PATH
mkdir repotest
copy the latest snapshot to your directory
cp -r /homes/repos/cvs/jboss/project_to_extract .
svnadmin create mytestrepo
cvs2svn --dumpfile=cvsdumpfile --dump-only path_to_project_to_extract
this will create a cvs dump file, make sure you are using the latest cvs2svn as a bug exists in older versions
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:
http://svn.jboss.org/repos/jboss
The location of our vendor source drops would be:
http://svn.jboss.org/repos/jboss/vendors/apache-logging
http://svn.jboss.org/repos/jboss/vendors/apache-beanutils
Let's walk through a real world example using apache-logging. What are the steps a developer would need to perform?
Get the source of the project you wish to add as a vendor branch
svn export http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk apache-logging
Note: if your 3rd party project uses cvs, you would use the cvs export command
Import the source into our vendor repository.
svn import /path/to/apache-logging
http://svn.jboss.org/repos/jboss/vendors/apache-logging/current
-m 'importing initial vendor drop'
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.
http://svn.jboss.org/repos/jboss/vendors/apache-logging/tags/1.0
-m 'tagging apache-logging with version 1.0'
Now it is time to make your fix. Check out the source (import does not convert you local tree to a working copy)
svn co http://svn.jboss.org/repos/jboss/vendors/apache-logging/current apache-logging
Make any necessary changes
Build and test
Commit your changes
svn commit -m "bugfix"
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.
Assumptions:
All source is currently in subversion
Procedure:
Obtain agreement in the forums or on the jboss-development list that it is acceptable to extract module.
Freeze development on the source for the module to be extracted
Open a jira task in the IT project. The removal of a module and extraction to a new repository is an admin level operation.
The steps involved for the IT group will be
Creating a new subversion repository
Performing a svnadmin dump using the a dumpfilter. This will essentially export the directory you are extracting with its history out of the repository.
Performing a svnadmin load using the previously created dumpfilter
At this point the new repository is setup and ready to use, the developer can check it out and resume development.
A binary artifact(s) should be created and added to the http repository, this will be used to integrate in the overall jbossas build
Cleanup of original module
Remove the source from the original module using svn delete.
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 https://svn.jboss.org/repos/jbossas/tags/JBoss_4_0_3_SP1/ https://svn.jboss.org/repos/jbossas/branches/JBoss_4_0_3_SP1_JBAS-1234 -m "Creating a branch for developing a patch" # Checkout the branch $ svn co https://svn.jboss.org/repos/jbossas/branches/JBoss_4_0_3_SP1_JBAS-1234 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.
An initial repository tree
A final repository tree
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 http://svn.jboss.org/repos/test/branches/Branch_4_0 jboss-4.0 #apply the changeset between the 4.0.3.SP1 tagged release and your patched branch to your working copy $ svn merge http://svn.jboss.org/repos/test/tags/JBoss_4_0_3_SP1 http://svn.jboss.org/repos/test/branches/JBoss_4_0_3_SP1-JBAS-1234 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 https://svn.jboss.org/repos/jbossas/admin
In that folder is a file called auth_conf, edit it, add usernames in the relevant location and commit your changes.
Migration
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 https://svn.jboss.org/repos/qa
cd scripts/cvs2svnmigration/mutation
ls
mutate MutateOne.sh NewMutateAll.sh
mutate is a directory which contains needed java classes for doing a mutation.
NewMutateAll.sh is a script used to mutate jbossas. It's saved here for historical purposes. MutateOne.sh allows you to mutate a branch or tag from a given project. It's documented in comments how to use.
Comments