ASCEND source code repository
Checking out a copy of the code
To check out a local copy of the ASCEND source code, use your subversion client (see About Subversion below) to checkout from the repository URL https://svn.ascend4.org/trunk/. To do this with the command-line client, you would typically use the following commands:
# we assume you want a folder called 'ascend' right there in your home directory cd ~ # check out the trunk of the repository to a new subdirectory called 'ascend' svn co https://svn.ascend4.org/trunk/ ascend
If you are behind a proxy, you may need to set proxy settings for your Subversion client. Alternatively, you may wish to access our bzr mirror of the trunk code, available from https://code.launchpad.net/~jdpipe/ascend/trunk.
You can also browse the repository online via ViewVC.
See Building ASCEND for information on how to build ASCEND from the source code you have checked out.
Please read our coding style guidelines.
To receive email notifications about changes to the trunk ASCEND code branch, use this page on Launchpad.
Working on the documentation and website
The documentation is available as part of the source distribution above. We do this so that we can link in sample code directly when compiling the documentation.
The source material for the public website (as opposed to this wiki) hosted is a separate part of the Subversion repository however. You can check out the website files using:
svn co https://svn.ascend4.org/web/trunk ascend-web
We don't currently have an automated publishing script; you will need to manually update the webserver if you make changes there in the repository.
Some Subversion automation
When making a commit to Subversion, you should be able to enter special strings like "fixes bug NNN", and those messages will be processed by the ASCEND Bug Tracker and used to modify the status of a bug which is relevant to your changes. (Need confirmation that this is still operating correctly).
If you use the the ASCEND Bug Tracker, then anytime you write comments containing text like "changeset 345", the text will be converted into a hyperlink that will allow you to click through to review the relevant code changes on ViewVC.
We have a number of active branches in our repository. Mostly these are related to student projects (eg GSOC2009 or GSOC2010) or else experimental forays that we don't want messing up things for others in the team.
To create a new branch,
then in the editor that pops up, give a description of your branch, eg "creating a new branch from trunk r3233 for dev of new code for boundary switching with IDA", save, exit.
To switch from one branch to another
# make sure you're in the top level working directory cd ~/ascend # update: sometimes it makes the switch cleaner to update your working code first svn up # do the switch svn switch https://svn.ascend4.org/branches/mynewbranchname
You will then see the branch that you are working in if you type svn info. If anything goes wrong with the switch, you can check where by running svn st.
Subversion is the version management software we are using.
For Linux, most distributions come with command-line subversion (command svn) already installed. GUI clients are also available. See the links on . There is also now a useful Nautilus extension called RabbitVCS.
For MacOS X, a recommended GUI client is scplugin. It allows you to access Subversion functionality for the context menu in the Finder. Alternatively, there is also a command-line version available for use from the Terminal.
Special requests for new developers
If you're a new developer on ASCEND, such as via GSOC, we'll normally grant you a username and password so that you can commit code to our repository. While you're starting out working with us, we'd make the following requests:
- make sure all your changes are committed to your personal branch, which you can normally checkout using svn co svn://ascend4.org/code/branches/username ascend. Please DO NOT commit code directly to the 'trunk'.
- familiarise yourself with our coding style.
- avoid making unneeded changes (eg formatting) where it can be avoided, except where discussed with your mentor.
- only add flat text files to our repository. Don't upload big documents, images or binary data files without discussing with us first.
- try to avoid committing multiple versions of the same file, eg "myfile1.c", "myfile2.c", "myfile3_broken.c", etc. Try to keep the development linear as far as possible.
- if you have got multiple independent areas of work you may wish to request an additional branch.
- when your work is at a stable and well-tested juncture, you can ask to have it merged into trunk.