Subversion

From Organic Design wiki
Revision as of 18:57, 1 June 2009 by Sven (talk | contribs) (moved SVN to Subversion)

OrganicDesign SVN

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).

Domain

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.

Security

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.

Problems

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 SVN

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;

<bash>

svn checkout http://svn.wikimedia.org/svnroot/mediawiki/folders_to_download </bash>

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 arrise when users try to checkout content that is maintained in a versioned directory structure referenced by symbolic links.

See also

MediaWiki SVN branches OrganicDesign is involved with

Command Overview

The typical work cycle looks like this:

Update your working copy
svn update
Make changes
svn add
svn delete
svn copy
svn move
Examine your changes
svn status
svn diff
Possibly undo some changes
svn revert
Resolve Conflicts (Merge Others' Changes)
svn update
svn resolved
Commit your changes
svn commit

Usage

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

SVN GUI's

Linux:  kdesvn (and many others) 
Windows:  tortoisesvn
Macos:  svnx

See also

Retrieved from "https://organicdesign.nz/wiki/index.php?title=Subversion&oldid=93560"