How To Deal With Subversion
Subversion is the software that manages the Gambas
source code repository on
A repository is exactly like a file system, but a file system that keeps
Gambas repository organization
repository is divided into three main directories:
This directory contains the sources of the development version. Its aim is becoming the next major version of Gambas.
This directory contains the sources of the stable version. There is one sub-directory for each stable version. Their aim is becoming the next minor version of the stable version.
One can find there some other development related to Gambas that are designed outside of /trunk, and that will be merged with it in the future.
This directory contains the sources of each released version of Gambas. There is one sub-directory for each version. They are just archives, and can be used for recreating a package of a past version.
You can read the repository contents from the web at this address:
Compiling the Subversion repository.
First, you have to download the sources.
Everybody can make a copy of the repository on his hard disk by using the following command:
$ svn checkout svn://svn.code.sf.net/p/gambas/code/gambas/trunk
$ svn checkout svn://svn.code.sf.net/p/gambas/code/gambas/branches/3.3
for a stable version.
Once done, you do the compilation exactly the same way as when you compile a source archive downloaded from the website:
$ ./configure -C
$ sudo make install
Getting a write access to the Gambas repository
If you want to do actual development or translations for Gambas
, then you need a write
to this repository.
To get a write access to the Gambas subversion repository, just create a user account on sourceforge.net, and ask me to grant a
write access to the user you just have created.
How does it work?
Each time anything is changed in the repository, the revision number
incremented, and a revision log
is attached to it. The revision log is
edited by the person doing the modification.
All is done with the svn
- svn checkout makes a copy of the repository on your hardisk, and adds many hidden .svn directories everywhere in it to track the changes.
- svn commit sends all your modifications back to the server, asks for the revision log, and increments the revision number. Each commit has its own revision number and revision log.
- svn update, upgrades your local copy of the repository to the latest version.
Someone may have modify some things between the time you checked out
the time you committed
. So before doing a svn commit
, you should do a svn update
Writing revision log
When you commit, you must specify the editor used for editing the revision log in the $EDITOR
$ EDITOR=gedit svn commit
Revision log format
I want to have a standard way to write commit messages, so that ChangeLog can
be almost automatically generated.
The format is the following:
- A ChangeLog slot, between '[' & ']'
- A ChangeLog modification: a '*', a space, the word 'BUG', 'NEW' or 'OPT', a colon, a space, and the text.
' is for a fix, 'NEW
' for a new feature, translation, or updated ones, and 'OPT
' is for an optimization.
Slots are the name of the component
in uppercase, or one of the following:
- [INTERPRETER] for changes in the interpreter (gbx3).
- [COMPILER] for changes in the compiler (gbc3).
- [ARCHIVER] for changes in the archiver (gba3).
- [INFORMER] for changes in the informer (gbi3).
- [DEVELOPMENT ENVIRONMENT] for changes in the IDE (gambas3).
- [CONFIGURATION] for changes in the automake/autoconf configuration process
- [WIKI CGI SCRIPT] for changes in the wiki CGI script.
- [WEB SITE MAKER] for changes in the Gambas web site generator.
- [EXAMPLES] for changes in any example.
All lines must be lower or equal than 76 characters.
If a changelog modification is more than one line, you must use a two space
Void lines are ignored.
All other lines won't go into the changelog.
I did this thing, and this won't go into the changelog.
* BUG: I fixed this bug.
* NEW: I made this very long modification....
and it takes more than one line to write it.
This won't go into the changelog too.
* BUG: What an awful bug!
* NEW: I finally finished the component :-)
Please follow this scheme. It would be really
There is a mailing-list that gets a mail each time somebody commits a new revision.
So this way you always know if you have the latest revision on your hardisk or not.
State of your repository copy
To get the state of your repository copy, run the svn status
Each state is described with one or more letter:
- ? is a file not managed by subversion.
- M is a file you have modified.
- C is a file in conflict.
- G is a file in conflict that was automatically solved by the svn command.
- A is a newly added file or directory.
- D is a deleted file or directory.
- ... and so on.
See above for more information about conflicts
No automatic project structure tracking
You must tell subversion if you add, delete, rename or move a file. You do that with the commands:
- svn add to add a file you have already created.
- svn del to remove a file.
- svn move to rename or move a file.
Somebody can modify a file in the repository, while you have modified the same
file on your hardisk. This is a conflict
, and svn
will tell you when running svn update
or the svn status
Each time there is conflict, svn
tries to solve it automatically, by merging your own changes with
the changes made by other people.
If the merge succeeds, your will get a file with a 'G' state character.
If the merge didn't succeed, your will get a file with a 'C' state character. Then you will have to solve
the conflict by hand:
- You must edit the file yourself to merge the changes. svn has modified the file so that you see your own changes and the other changes side by side.
- Or you can use one of the copy automatically made by subversion. You get one for the latest version, and one for the current version of your local repository. Their name are the name of the original file followed by a dot, the letter 'r' and the revision number. Just replace the original file by the copy.
Once done, you will tell svn
that the conflict is solved by running the svn resolved
command on the file in conflict.
Is there any risk?
Normally there is no risk, as everything is archived, and so you can always go back in
Moreover, if you work on a Gambas
project inside the repository, the development environment
can deal with all svn
command for you. Go to the versioning
tab in the project property
dialog, and you will find buttons that allow you to update the project, commit it, and cancel
If you have made something weird, you can use the svn revert
command. It will revert
your local copy to the state of the last checkout or update.