Difference between revisions of "Subversion"
Revision as of 18:57, 1 June 2009
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.
/var/svn/peerd /var/svn/peerix /var/svn/www /var/peerd /var/peerix /var/www
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:
svn: Can't convert string from native encoding to 'UTF-8': svn: A?\195?\164o?\195?\188.gif
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. It is straightforward to checkout extensions with the command;
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
svn add svn delete svn copy svn move
- Examine your changes
svn status svn diff
- Possibly undo some changes
- Resolve Conflicts (Merge Others' Changes)
svn update svn resolved
- Commit your changes
The most important command to know is how to get help;
svn help svn help checkout # Help on check(ing)out project to CLIENT copy svn help commmit # Help on commit(ting) changes to SERVER
To obtain a log of the changes made in a svn project;
svn log -v http://[PATH TO SERVER SVN PROJECT]
To create a new repository on the server ready for importing a directory of files;
cd /tmp mkdir SERVER svnadmin create /tmp/SERVER/newrepos
This creates a concise database directory for the new repository on the SERVER in the directory called /tmp/SERVER;
ls -l /tmp/SERVER/newrepos total 16 -rw-r--r-- 1 User wheel 379 Apr 3 13:58 README.txt drwxr-xr-x 4 User wheel 136 Apr 3 13:58 conf drwxr-xr-x 2 User wheel 68 Apr 3 13:58 dav drwxr-xr-x 10 User wheel 340 Apr 3 13:58 db -r--r--r-- 1 User wheel 2 Apr 3 13:58 format drwxr-xr-x 11 User wheel 374 Apr 3 13:58 hooks drwxr-xr-x 4 User wheel 136 Apr 3 13:58 locks
Create an example directory for upload;
cd /tmp mkdir MYTREE echo '#!/usr/bin/perl -w\nprint "hello world";' > /tmp/MYTREE/helloWorld.pl svn import /tmp/MYTREE file:///tmp/SERVER/newrepos/some/project
Listing the contents in the repository directory path;
svn list file:///tmp/SERVER/newrepos/some/project
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.
mkdir CLIENT cd CLIENT svn co file:///tmp/SERVER/newrepos/some/project/ # fetches project/test.pl svn co file:///tmp/SERVER/newrepos/some/ # fetches some/project/test.pl rm -rf /tmp/CLIENT svn co file:///tmp/SERVER/newrepos/some/project/ /tmp/CLIENT # Creates CLIENT dir
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;
cd /tmp/CLIENT # Work in the local copy of svn
To update a file on your CLIENT directory;
cd /tmp/CLIENT svn update # "." is updated cd /tmp svn update /tmp/CLIENT # Specifying path
To add a new file to the local svn copy, first make a new file within the directory structure;
cd /tmp/CLIENT echo '#!/usr/bin/perl -w\nprint qq(hello world!);' > /tmp/CLIENT/helloWorld2.pl svn add helloWorld2.pl
The status command will identify differences between the CLIENT copy and the SERVER copy of the repoistory;
svn status /tmp/CLIENT
The following list provides the details of svn status output;
L abc.c # svn has a lock in its .svn directory for abc.c M bar.c # the content in bar.c has local modifications M baz.c # baz.c has property but no content modifications X 3rd_party # this dir is part of an externals definition ? foo.o # svn doesn't manage foo.o ! some_dir # svn manages this, but it's either missing or incomplete ~ qux # versioned as file/dir/link, but type has changed I .screenrc # svn doesn't manage this, and is configured to ignore it A + moved_dir # added with history of where it came from M + moved_dir/README # added with history and has local modifications D stuff/fish.c # this file is scheduled for deletion A stuff/loot/bloo.h # this file is scheduled for addition C stuff/loot/lump.c # this file has conflicts from an update R xyz.c # this file is scheduled for replacement S stuff/squawk # this file or dir has been switched to a branch
To upload the CLIENT copy changes to the SERVER copy use the commit command;
svn commit /tmp/CLIENT
Cleaning up directories in /tmp;
rm -rf /tmp/SERVER /tmp/CLIENT /tmp/MYTREE
Linux: kdesvn (and many others) Windows: tortoisesvn Macos: svnx