Eventually we'd like to have an proper web-browsable SVN repository like WikiMedia. We don't need SVN for content backup as we're now using Unison for that (see the Set up a distributed file system project).
The domain svn.organicdesign.co.nz is pointing at the server (see organicdesign.vhost for details), and the following repositories and their associated directory structures have been set up. Currently only the peerd repository has had the data imported from its associated directory structure since there is currently no security in place.
The directory structures that are in day-to-day use such as /var/www will then be synchronised regularly on a cron job with the repositories in the same way as any of the users local versions.
I've set up SSL using a self-signed certificate for www.organicdesign.co.nz which allows connection to all the wikia via either HTTP or HTTPS but will give a warning message on first connection (or maybe on every connection depending on the browser). I haven't enabled SSL for the svn setup currently as I'm not sure how to do this yet.
When attempting to import the /var/www structure into the /var/svn/www repository it bailed after coming across a filename containing special characters with the following fatal error:
To set up later
Exclusions: we don't need cache data such as files/thumb directories being included in synchronisation...
Inclusion of local user data in our distributed backups
This idea could also tie in with the new Extension:SimpleUploads idea of users being able to maintain their own on-line file structure. Since these files would be part of the svn repository they'd get included in the local updates and effectively we'd all have automatic distributed backup of our files. These files could include our important local files too like emails etc simply by ensuring that they're stored in our own user area of our local repository. We could then just run crons to keep them updated in both directions. Edit conflicts would not be a concern with any of this since we're talking about our own user-files which are not accessed by anyone else.
MediaWiki's SVN uses SSH public key so you don't need a password, so you'll need to supply your ~/.ssh/id_rsa.pub file to the person setting up your commit access (if that files doesn't exist, run ssh-keygen from non-root shell using blank passwd when prompted, see this link for details). Also, you need to set up your auto-props. Note also that the commit's are automatically shown on the #mediawiki IRC channel (see freenode FAQ re registering a nickname etc) so it's good to have that open when working on the MediaWiki code.
See MW:Subversion for details about using MediaWikis SVN. The following examples download the current code-base and an extension:
The ease of directory structure construction suggests that extensions maintained in an svn do not require any symbolic link manipulation as suggested in the article OD/Wikia, otherwise a conflict will arise when users try to checkout content that is maintained in a versioned directory structure referenced by symbolic links.
MediaWiki SVN branches OrganicDesign is involved with
- config/index.php - The MediaWiki installer script
- Database.php - General database class
- DatabaseSqlite.php - SQLite database layer
- DatabaseMssql.php - Microsoft SQL Server database layer
- AutoLoader.php - List of potentially loaded classes
- maintenance/mssql - MSSQL table definitions and docs
- maintenance/sqlite - SQLite table definitions and docs
- Category:Extensions in the MediaWiki SVN repository
The typical work cycle looks like this:
- Update your working copy
- Make changes
- Examine your changes
- Possibly undo some changes
- Resolve Conflicts (Merge Others' Changes)
- Commit your changes
The most important command to know is how to get help;
To obtain a log of the changes made in a svn project;
To create a new repository on the server ready for importing a directory of files;
This creates a concise database directory for the new repository on the SERVER in the directory called /tmp/SERVER;
Create an example directory for upload;
Listing the contents in the repository directory path;
To make a local copy you need to use the checkout command. This creates a new directory (default called newrepos) which is a local copy of newrepos.
Note: The directory the svn command is run in determines where the local checkout directories and files will end up.
Now that you have created a local copy all work should be conducted within it. There is a hidden directory called .svn which contains all the information required for the svn framework;
To update a file on your CLIENT directory;
To add a new file to the local svn copy, first make a new file within the directory structure;
The status command will identify differences between the CLIENT copy and the SERVER copy of the repoistory;
The following list provides the details of svn status output;
To upload the CLIENT copy changes to the SERVER copy use the commit command;
Cleaning up directories in /tmp;
- Configure SVN - our procedure for setting up SVN and WebSVN on our servers
- Setting up websvn on Debian/Apache
- Jeremy Knope's tutorial
- Svn Cheatsheet
- Secure subversion
- cvs to svn Experiences
- subversion cheatsheet
- Centrestage tutorial
- BioConductor SVN tutorial
- Subversion book
- CodeSwarm - renders video's of subversion repository activity