First steps with your new SVN account

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
Caution.gif This page is obsolete.

Use the information here with caution. See the Table of Contents.


This tutorial is about what to do when you are a fresh owner of a new SVN account for ADempiere.


  • SVN is used to describe a SVN server, mostly ADempiere's or the ADempiere's anonymous SVN servers.
  • The lower case word svn is used to describe the program named svn, which the user can use to access SVN.
  • By username the name of your ADempiere SVN account is meant (also known as login).


This tutorial assumes that you have applied for a ADempiere SVN account like described here and that you have received a positive answer with the data of your new account.

Changed URLs

Until now, you have worked with one of the anonymous SVN servers. Now that you have a ADempiere SVN account, you will not use that anonymous server anymore. Therefore the base URL to the SVN server changes for you.

For the standard anonymous SVN of ADempiere, it was:

Note: if you are unsure which SVN anonymous server you have used, you can look at any of the .svn/entries files and see the URL of the server there.

Now the new base URL for your access to the ADempiere SVN server depends on which way you have chosen to access it:

where username is the name that was given to your ADempiere SVN account.

Changing The URLs of the Modules of Your Local SVN Copy

To use the ADempiere SVN server instead of one of the anonymous SVN servers, you need to tell each module of your local SVN copy that you want to change the server. SVN does this with the command svn switch --relocate.

Assuming that you are processing the libs module, you have to use:


For other modules than ADempiere libs (or for branches or for tags), you have to change the relative module path; similarly, if you used another anonymous server.

Be careful on what URLs you type, as SVN will only replace the exact old URL by the exact new URL. So if you mistype one of the URLs, it will not work later. (If you have already fallen into this pitfall, it is not a problem, just use relocate again to replace the wrong URL by the right one.)

If you connect by https, as the first relocation will be the first contact to the ADempiere SVN server with your new SVN account, you will be asked to confirm the SSL certificate of the server and then you will be asked to authentificate yourself.

The fingerprint for the SSL certificate can be found in the document Using Subversion with ADempiere. (Normally, the SHA1 fingerprint is used.)

(TODO: what happens in the case of svn+ssh ?)

A quick troubleshooting note: if you cannot access the server with your new account made for accessing by https, you can try to give the https path in Konqueror. You will not be able to do much with Konqueror, but at least you must be able to login. That helps to know if the problem is more the server or your account or if the problem is svn. If you cannot login at all and you cannot find why, ask the Sysadmins for help.

First Test

The following steps are described using the command line tool svn. Personally, I find it better to start with it, as you know immediately where the problems are. Of course, after you have made your first test, you may use whatever tool that you prefer.

Then you should be ready to start. The best test is to try to update a small directory. So change to a (small) directory of your local copy of ADempiere and type: svn update.

Now you can use the SVN commands on ADempiere's main SVN.

Note: if you know CVS, you will perhaps wonder that there is no cvs login, Subversion has chosen not to have such a way to login. The login is done at the first connection, where authentication is needed.

SVN Account Password

This section is only for accessing ADempiere SVN by https. For SSH, it is SSH that secures the connection, so normal SSH habits and procedures apply.

The password is automatically transmitted to the SVN server by each use of the SVN program when accessing by https.

Please note: the password is stored somewhere in the directory ~/.subversion/auth . So please check that these files cannot be read by third persons, as the password is unencoded.

In case that someone has gained access to your password (or if you have a doubt) please email ADempiere's Sysadmins to change your password (or at least to get it disabled temporarily.)

Default Editor

This section is only useful if you plan to use the svn program. If you always plan to use a GUI front-end, you can skip this section.

When committing, svn wants some text for commenting the commit. You can either specify it directly with the -m parameter or by a file with the -F (or --file). If you do neither of both, svn will run an editor to ask for a comment.

This editor is taken either from the svn configuration files or if not defined there from the environment variables: first $SVN_EDITOR, then $VISUAL, then $EDITOR depending which one is defined.

So may be you should check your environment variables: echo $SVN_EDITOR echo $VISUAL echo $EDITOR

Check that their settings suit you for your work with svn. If they do not suit you, check your file ~/.bashrc and add something like: export SVN_EDITOR=mcedit Here it sets mcedit, replace it with your favorite editor. Of course you can set $EDITOR instead if you want to change the default editor for you.

Be careful that if you do not set a command line editor but one that needs X-Window, you will need to run svn always in a X-Window terminal. It might suit you, it might not. Your choice!

Subversion configuration

For proper of "svn status" and "svn diff" on ADempiere sources, you might want to follow the instructions from the developer FAQ for setting up ~/.subversion/config. Committing

Now a few words about how to commit.

First be sure that the code that you want to commit is right. You might perhaps send the patch to the relevant mailing list or to the relevant developer if you know who he is.

Also when committing, please give a useful message with the commit. Do not think of now but try to think what you would want to find in, say, two years. (One day, you will probably find out that meaningless commit entries like "Fix" or "Here too" are going to drive you crazy when you have to debug a problem.)

Good code is not always only about questions like: "Does the code compiles?" The code must also fit in what is planned. For example if a new code fixes just one little bug but the maintainer of the code is currently doing a re-write, he will perhaps not be pleased that something has been committed, because he will have to fix all conflicts between the newly committed code and his new code.

So the best is to communicate (if possible early) to avoid any surprise. A surprised developer is highly at risk of giving a rude answer or at least not a pleasant answer. This is avoidable by communication. Of course, a developer might ask to leave the code alone. Please respect that! (Of course, it does not mean that you should not argue.)