Subversion
Our source code is hosted on the Subversion server svn.gnucash.org. For accessing the repository, you can choose many methods. The most direct method is using subversion as a client (also called svn). This is explained on this page.
Alternative access methods:
- As a strongly suggested alternative (and used by several of the developers), you can use git and git-svn as a method of accessing the source code.
- Or you can use the since 2010 discontinued svn-svk SVK.
- There is also a branch available via bazaar which is very quick to check out.
Contents
Repository URLs
The various base URLs look like:
anonymous: http://svn.gnucash.org/repo/gnucash/trunk developer: svn+ssh://username@svn.gnucash.org/repo/gnucash/trunk trac: http://svn.gnucash.org/trac
Note: If you are having problems with the http:// anonymous access, make sure your subversion is compiled with neon support.
Note: If you are behind a proxy (http firewall), you need to manually set the proxy name and authentication information in one of your local svn configuration file, namely in $HOME/.subversion/servers . Just open that file with a text editor and scroll to the end; you will find instructions there on how to set the variables. See also http://subversion.tigris.org/faq.html#proxy
Warning: Somebody working also on the documentation and/or the web page could try to use http://svn.gnucash.org/repo/, but that would produce ~10 GiB mostly of dead branches and svn up would become very slow.
SVN and Microsoft Windows™
There are two ways to use Subversion with Microsoft Windows™:
- One is the subversion client built with MinGW (not provided as part of MSYS, but the Windows build script will build it as part of the process.
- The other is TortoiseSVN.
The client built by the install script is a command line client that works only in the MSYS command shell. It is exactly the same client used on Linux and MacOSX systems, and its use is summarized below.
TortoiseSVN is a Windows™-native implementation with a nice GUI that integrates into the context menu of Windows™ Explorer. Users without commit privileges can simply create a folder, select it in Explorer, right-click, and select "TortoiseSVN Checkout..." from the context menu. A dialog box will open into which one can type the anonymous URL (committers have a bit more involved setup) and click OK. Once you've checked out the repository, you can use the TortoiseSVN context menu to view logs and history.
Common Commands
To get what used to be CVS HEAD, you will need to get the svn TRUNK:
svn checkout http://svn.gnucash.org/repo/gnucash/trunk gnucash
The argument "gnucash" above can be whatever you want your local directory to be called, and is optional. If you leave it out, you'll have a directory called "trunk" created containing all the source code.
If you want the latest 2.4.x code, you'd need to pull from the 2.4 branch, as follows:
svn checkout http://svn.gnucash.org/repo/gnucash/branches/2.4 gnucash-2.4
And if you want the released code for a specific release (or tag), you'd use:
svn checkout http://svn.gnucash.org/repo/gnucash/tags/2.4.3 gnucash-2.4.3
And to update, just cd into the directory containing the sources you want updated and execute a simple
svn update
To switch a TRUNK working copy to the 2.4 branch, cd into the directory containing the sources you want updated and do this:
svn switch http://svn.gnucash.org/repo/gnucash/branches/2.4
You probably want to continue reading at the Building page. Otherwise, continue on below for information on how to use subversion.
SVN tutorial
Now that the gnucash repository is using svn for version control (since 2005-11-04), the need for a quick tutorial on how to get the sources might be in order. There was some introduction about SVN in an e-mail on gnucash-devel:
The excellent "Version Control with Subversion is a very good resource for information about subversion.
Specifically, Chapter 3. Guided Tour and Appendix A. Subversion for CVS Users are relevant.
The command-line client `svn` has a nice integrated help system; `svn help` will provide the top-level command list, and `svn help <command>` detailed help for the specific command.
The bottom line is that getting the source via svn isn't altogether different from getting it using cvs.
CVS to SVN cross reference
CVS command | SVN command | Notes |
---|---|---|
cvs checkout | svn checkout | |
cvs commit | svn commit | |
cvs status | svn status | ...but the svn one is actually useful :) |
cvs log | svn log | |
cvs annotate | svn blame | |
cvs diff | svn diff | |
cvs diff -D 2006-01-01 | svn diff -r {2006-01-01}:HEAD | |
cvs update | svn update, svn switch | |
cvs update -C | svn revert | |
cvs update -j [...] | svn merge | |
---- | svn resolved [conflicting merges must be explicitly resolved] | |
cvs add | svn add, svn mkdir | |
cvs remove | svn delete | |
---- | svn move | |
cvs [r]tag [-b] | svn copy |
Enjoy!
Maintain a local copy of the repository
Note: For keeping track of the various branches in SVN and have patch creation made much much easier, it might be very helpful to use one of the many tools to maintain a local copy of the SVN repository. Some of these options are:
- git with git-svn
- Maintaining a SVN repository on your own: How to maintain your own local subversion branch of someone else's repository, keep it synced with changes upstream, and generate patches: http://www.parit.ca/Weblog/archive/2008/07/05/keeping-up-with-the-joneses-svn-repo
- Bazaar with bzr-svn
SVN write access
FAQ: Is it possible to get SVN write access?
A: In principle yes, but we are quite conservative with giving out new SVN write accounts. For occasional changes people are encouraged to submit patches. We do add people as developers if they stick around, supply lots of patches, become highly involved in the project, hang out on IRC, and generally show some level of clue and prove some level of trust. But in the meantime, patches in Bugzilla are the suggested route, as has been stated at other places. --Cstim 08:00, 8 January 2006 (EST)
Subversion for Committers
Preparations
When you are granted committer privileges, the repository administrator will arrange with you to create a username and to transfer to him a public key to use with subversion. You'll use subversion the same way, except that the URL will be ssh+svn://username@svn.gnucash.org/repo. The key should be a 1024-bit or larger RSA key in openssl format. Openssl is provided by most Linux distributions and is built in to MacOSX. To generate a key:
ssh-keygen -b 1024 -t rsa
You will be prompted for a filename, with a default of ~/.ssh/id_rsa. That is the correct filename to use if you have only one key -- and if you have more than one, you already know enough about SSL that you don't need these instructions.
You will also be prompted for a passphrase, with the option to leave it blank. If you provide a passphrase, you will be prompted to provide it every time you use your key. If you don't, anyone who gains access to your key can connect to whatever servers you protect with it.
Once you have the key configured correctly, try to ssh to svn.gnucash.org. If everything is set up correctly, you'll get a message Shell login to CVS server not permitted and the connection will drop. You're ready to connect with subversion. If not, you'll have to contact the repository administrator for help.
Microsoft Windows™
To set up ssh with the MSYS client, proceed exactly as above.
For [TortoiseSVN], you'll also need PuttyGen and Putty from [PuTTY]. Setting up Pageant to work with TortoiseSVN is a bit involved, so we'll go through it step-by-step:
1. Use PuttyGen to convert your private key into Putty format. Launch puttygen, click the "load" button and select your private key file, then click the "save private key" button to save it in putty format.
2. Set up a Putty profile: Start Putty.
- Set the Host URL to svn.gnucash.org, port 22 on the Session page
- Open Connection:SSH:Auth and at the bottom of the panel, for "Private key file for authentication" browse for the converted keyfile you made in the previous step.
- Open Connection:Data and enter your username in the "Autologin username" text entry.
- Return to the Session panel, enter a name (if you use svn.gnucash.org configuring TortoiseSVN will be less confusing) in the text entry named "Saved Sessions" and click the "save" button.
- Click "open". If everything is done correctly, a command window will open and you'll see that message about terminal sessions not being allowed. If you are instead prompted for a password, you have messed up the username or key somehow and will need to contact the server admin to get your IP address unblocked.
3. Set up TortoiseSVN:
- Right-click a folder in Windows™ Explorer and select TortoiseSVN:Settings. At the bottom of the Network panel of the resulting dialog box, click the "Browse" button for SSH Client and navigate to C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe, click "open" in the file chooser, the "OK" to dismiss the Settings box.
- Right-click on a folder into which you want to check out (or already have checked out) Gnucash. If it's a fresh checkout, select TortoiseSVN Checkout; otherwise select TortoiseSVN:Relocate. Enter the URL as ssh+svn://the-putty-session-name/repo/gnucash/trunk. (Remember earlier where we said it would be less confusing if you use svn.gnucash.org for the session name? That's because if you did the URL will be svn+ssh://svn.gnucash.org/repo/gnucash/trunk.)
You should now be able to commit changes via TortoiseSVN.
Commit Conventions
Your commit should have a comment explaining your change.
Link Bugzilla Entries
Often commits are related to Bugzilla entries. In this case the first line should contain
- Bug #<bug number>:<bug title> or
- Bug #<bug number> - <bug title>.
If trac sees the hash sign (#), it should create a link to that bugzilla entry.
Backport Rules
While usually commits will be applied to trunk, sometimes it is desired to backport them on the stable branch, currently 2.4. There are a few rules to decide, if a commit should be backported:
- If the commit fixes a bug that was reported in bugzilla against the stable branch, the changeset should be backported, but:
- The backporting effort should be trivial. If complicated manual intervention is required, backporting should be skipped to maintain stability.
- Backports should not require new or stronger dependencies.
- If the changeset modifies the data model, it should be split in 2 parts:
- The part to read the modified data model should be backported.
- The part to write the modified data model should only be applied on trunk.
- This would allow a user to test a new main release on one computer while still using the older version on another computer or later on the same computer again without data loss.
If you wish to backport your commit on trunk should contain the mark BP in a separate line of the comment. That would trigger the prefix AUDIT to the mails sent to the gnucash-patches and gnucash-changes lists.
Current Backport Policy
While it would be better new patches would be committed on trunk and only backported at release date, the current release manager does not have the resources to do that. So it is up to the committer to backport his commits where required.
Backport comment format
If you backport your changeset the commit comment should contain
- [<changeset>] <comment>, where changeset refers to the svn revision, of the apply on trunk and the comment should be the same as the first line of that changeset -> No BP mark.
Other options exists as well; feel free to edit this wiki page.