Using Subversion and Xaraya
In the previous article I went into how and why I chose Subversion for my revision control system for my own projects. And not just new ones, I have a slew of Xaraya projects that I continue to maintain and improve which need to get into svn. Here's what it takes to do that. And I wrap it up into an sh script. My platform is OSX on an iMac.
To install subversion, if you have MacPorts, just run
$ sudo port install subversion +tools
Create Project Repository
My repository is in ~/svn . We'll build an initial directory layout with trunk/ tags/ and branches/ directories, as recommended (by everyone):
$ mkdir ~/svn
$ svnadmin create --fs-type=fsfs ~/svn/myproject
$ svn mkdir --message="Initial project layout" $REPOS/trunk $REPOS/tags $REPOS/branches
Add All Files
I'm going to assume you already have a Xaraya project installed, in a myproject directory. We start by checking out the (empty) trunk and then adding all the files in the project.
$ cd myproject
$ svn checkout $REPOS/trunk .
$ svn add --force .
Remove Files We Won't Keep
Remove (revert) any added files that we know we don't want to keep in the repos. For example,
$ svn revert .htaccess
$ svn revert favicon.ico
$ svn revert -R var/*
The var/ subdir contains the cache and other runtime files we don't want in the repos. But we might want to keep the config file, so let's add it back
$ svn add var/config.system.php
The var/messaging dir contains site-specific templates so lets keep that one too.
$ svn add --force var/messaging
Remove Xaraya Code (optional)
If you don't want to keep the Xaraya code itself in the repos, you can remove it. But we'll keep the modules/ directory name around so we can selectively add specific modules back in (thus rever "modules/*" rather than "modules").
As for theme, I consider Xaraya_Classic unchangeable, so I can revert to it if my own theme really screws up. You might want to remove other themes in the themes/ directory if you don't change them either.
$ svn revert *.php
$ svn revert -R includes
$ svn revert -R xaradodb
$ svn revert -R modules/*
$ svn revert -R themes/Xaraya_Classic
If you've made any custom changes to individual modules, you can add those back in. In particular, my projects tend to have custom files in modules/xarpages/xarfuncapi, xardecodeapi, xarencodeapi, and xarcustomapi directories. For example
$ svn add --force modules/xarpages/xarfunapi
$ svn add --force modules/xarpages/xarcustomapi
$ svn add --force modules/xarpages/xarencodeapi
$ svn add --force modules/xarpages/xardecodeapi
Note that subversion saves symbolic links as a file, it does not follow the links. So this won't work if modules/xarpages is a symlink. For example, often I keep a single copy of a Xaraya release in a separate part of my disk, and symlink to it from various projects.
When we get listings from "svn status", all these non-working files show up even though they're not revision controlled, and that can get confusing. So tell subversion to ignore (and not show) them.
$ svn propset svn:ignore ".htaccess
$ svn propset svn:ignore "*" var
Note the list of file patterns are "newline-delimited" (why?) per the svn manual.
Finally commit all the stuff we've setup
svn commit --message="Initial add"
One last thing, I want to set a property with the Xaraya version used in this project. This really isn't specified in any of the files we've added to the repository and it needs to get recorded.
svn propset xaraya "1.2.1" .
That's about it.
Here's a shell script that does this. You can run it on an existing Xaraya project. Afterward you'll likely still need to run additional svn commands to add all the project files you want in the repository (or use a handy GUI front-end).
Usage: xar-svn PROJECT [VERSION]
The script assumes your project directory is a subdir of the current one. Thus, for example,
$ cd ~/www
$ xar-svn myproject 1.2.1
This will create a repos for myproject, check in all the files in ~/www/myproject/, except for the core Xaraya program files, and give the trunk a property "xaraya" with value "1.2.1".
This script is derived from here , and the same disclaimer applies: NO IMPLIED WARRANTY. This script might destroy twenty years worth of work, and I cannot be held responsible.