- 1 Background
- 2 Instructions
- 2.1 Install IPKG
- 2.2 Setup telnet
- 2.3 Install subversion
- 2.4 Editing files
- 2.5 Configure
- 2.6 Alternative user, group and repository management (windows only)
- 2.7 Run
- 2.8 Startup using autorun.sh
- 2.9 Startup using qpkg conf
- 2.10 Apache HTTP
- 3 Client
- 4 Email Notification on SVN Activities
- 5 See also
Subversion (SVN) is a version control system initiated in 2000 by CollabNet Inc. It is used to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly-compatible successor to the widely used Concurrent Versions System (CVS).
The svnserve program is a lightweight server, capable of speaking to clients over TCP/IP using a custom, stateful protocol. Clients contact an svnserve server by using URLs that begin with the svn:// or svn+ssh:// schema.
At the moment Subversion is not included in the firmware of the QNAP. Hopefully it soon will be avaible as a QPKG package so it easily could be installed through the webinterface. But until further notice it has to be installed through ipkg.
The first step in the installation is to Install Optware IPKG through QPKG.
Telnet must be enabled from the QNAP web page. For win7 users, this link shows how to run telnet:
Connect and log into your QNAP using SSH or Telnet (e.g. PuTTY).
Then use ipkg to install Subversion:
# ipkg update # ipkg install svn
Note that the above commands will automatically download and install subversion automatically.
Maybe you need to add '/opt/bin' and '/opt/sbin' to the PATH environment variable. It is a good idea to ensure that these directories exist in the /etc/init.d/Optware.sh file.
As a temporary fix you can do this either by the export command:
# export PATH=$PATH:/opt/bin:/opt/sbin
or by add them to these files:
Please note that the only way to ensure that the '/opt/bin' and '/opt/sbin' files are in the PATH environment variable permanently is to ensure that the below block of code is there in the /etc/init.d/Optware.sh file. Make sure you open this file and verify accordingly.
# adding Ipkg apps into system path ... # /bin/cat /etc/profile | /bin/grep "PATH" | /bin/grep "/opt/bin" 1>>/dev$ # [ $? -ne 0 ] && /bin/echo "export PATH=/opt/bin:/opt/sbin:$PATH" >> /et$
If everything else fails and the svn command is not getting recognised due to path issues (a known issue for which a fix is available as indicated above) and svn installation has succeed then you can prefix /opt/bin/ to make use of the svn, svnserve and svnadmin commands as applicable.
The following instructions require some editing of config files. This can be done with the vi text editor. The following link has a summary of the commands in vi:
If vi has an error 'terminal capability "cm" required', then type this in telnet:
Decide where you want all the files to be located on the QNAP. Remeber to put these files in a private folder because it will contain config files and so on. So, create the folder and initialize it for sharing with svnadmin:
- Create the repository folder somewhere on your harddisk!
- An earlier description was to create the repository in /share/svn. This is wrong!
- Depending on your QNAP model your harddisk(s) are mounted e.g. to /share/HD?_DATA or /share/MD?_DATA (? is one character from A..Z) .
- The directory /share itself belongs to /dev/ram, so if you create mkdir /share/svn your repository will be located in the ram disk and after reboot your repository doesn't exist anymore.
- Also the capacity of the repository is limited to the free space in the ram disk.
- This is a different effect, reported in the QNAP forum, also caused by this problem.So replace /*/ in the following commands with a path on your harddisk e.g. /MD0_DATA/.
- It might be a good idea to ensure that you have the right folder path setup by creating a temporary file in the directory path that you have decided on and restarting the QNAP NAS device to ensure that the files still exist in the directory.
- Otherwise you might find that you have spent hours configuring an SVN repository in the RAM disk and lost data when the NAS has been restarted.
- Replace * below with the correct path for your device.
To find out what drives are mounted, use the following command. It will list the drives.
For one repository/project:
# mkdir /share/*/svn # svnadmin create /share/*/svn
For several repositories/projects:
# mkdir /share/*/svn # mkdir /share/*/svn/repos1 # mkdir /share/*/svn/repos2 # svnadmin create /share/*/svn/repos1 # svnadmin create /share/*/svn/repos2
Note! To delete a repository just delete the folder containing the repository:
# rm -r /share/*/svn/repos1
Now we want to configure the users and access to the repository. Replace <name of repository> to the actual name of the repository below.
You'll need to edit these files:
/share/*/svn/<name of repository>/conf/passwd /share/*/svn/<name of repository>/conf/svnserve.conf
You'll want to make sure you have write access somewhere to the repository. If you just uncomment the following, you should be able to use the repository using the default usernames/passwords. It's a good idea to have a different username per person, so that changes are more easily tracked. Note that white spaces in the beginning of a line is no accepted in the .conf files.
Valid options for anon-access and auth-access are read, write, none.
So uncomment in svnserve.conf:
[general] anon-access = read auth-access = write password-db = passwd
And these in passwd:
[users] harry = harryssecret sally = sallyssecret
Alternative user, group and repository management (windows only)
On windows, you can choose to use VisualSVN server to manage users, groups and repositories without ever touching any configuration file. Make sure the svn folder is shared. Do a full install of VisualSVN server, and then pick the shared folder of your SVN as the "Repositories root". You can start the server on the nas with the following command (replace the path with your chosen path):
svnserve -d -r /share/svn
You can now add new repositories in VisualSVN, and set up users and groups. This makes it's management a lot easier when you have multiple repositories and users, in for example a commercial setting.
To start the Subversion daemon run some of the following commands. Here is the standard port number 3690 used as example, but you can choose anything you like that's not being used already
Please note that 3690 is the SVN standard TCP/IP port but it is free for modification, just configure appropriately in the SVN client.
If one repository/project is used, the easiest way for later connecting is to use the following command (pointing at the one and only repository):
# svnserve -d --listen-port=3690 -r /share/*/svn
If you are going to use more than one repository/project, you need to start the server with the following command (it will share all avaible repositories):
# svnserve -d --listen-port=3690
At this stage, svn should be running, but it will not start automatically next time qnap is restarted.
The following command shows whether svnserve is running:
# ps |grep svn
To kill svnserve, using the process id number listed above:
# kill -9 <process_id>
Startup using autorun.sh
Autostart svnserve each reboot by putting this into Autorun.sh (the 'sleep 10;' is necessary for not initializing svnserve too early):
(sleep 10; svnserve ... ) &
A more robust approach is to wait for the svn executable to be in /opt/bin (which is the purpose of sleep). Assuming the optware ipkg is installed under /opt:
(while test ! -x "/opt/bin/svnserve"; do sleep 5; done; /opt/bin/svnserve ...)&
Startup using qpkg conf
An alternative autorun.sh is to edit the qpkg.conf file, described in this forum thread:
Regardless of whether using autorun.sh or the svnstart.sh approach, remember to set permissions using chmod on the newly created file.
Two ways to resolve the sqllite incompatibility issue:
create a simple ipkg init script which set LD_LIBRARY_PATH right in apachectl script.
The script is run on every start of QNAP fix apachectl and restart apache webserver if necessary.
This should be a permanent solution over updates, since in Way 2 the symbolic link is alway lost due to run of ldconfig or other QNAP updates...
# vi /opt/etc/init.d/S01-fixapachectl #### set right LD_LIB_PATH in apachectl to search /opt/lib on apache start if ! grep -i 'LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/opt/lib"' /usr/local/apache/bin/apachectl >> /dev/null ; then /opt/bin/sed -ie '2i LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/opt/lib" \nexport LD_LIBRARY_PATH' /usr/local/apache/bin/apachectl # restart apache /etc/init.d/Qthttpd.sh restart fi
Make the file exeuctable and run once
# chmod 777 /opt/etc/init.d/S01-fixapachectl # /opt/etc/init.d/S01-fixapachectl
Way 2: Modify the symbolic link /usr/lib/libsqlite3.so.0 to point to /opt/lib/libsqlite3.so.0. This resolves the sqllite incompatibility issue.
# ln -sf /opt/lib/libsqlite3.so.0 /usr/lib/libsqlite3.so.0
Create file /etc/config/apache/extra/apache-svn.conf with the following content:
LoadModule dav_svn_module /opt/libexec/mod_dav_svn.so LoadModule authz_svn_module /opt/libexec/mod_authz_svn.so # # Example configuration to enable HTTPS access for a Subversion # repository, "/share/MD0_DATA/svn". # <Location /svn> IndexOptions Charset=UTF-8 DAV svn SVNParentPath /share/MD0_DATA/svn SVNAutoversioning on # Limit write permission to list of valid users. # Require SSL connection for password protection. SSLRequireSSL AuthType Basic AuthName "Subversion" AuthBasicProvider external AuthExternal pwauth AuthzUnixgroup on require valid-user </Location>
Include your config to the main Apache config /etc/config/apache/apache.conf after apache-dav.conf configuration
# /etc/init.d/Qthttpd.sh restart
To communicate with the server you need to install svn client. You can find some of them here:
If you got a package manager, such as 'apt' (e.g. Ubuntu Linux) or 'pacman' (e.g. Arch Linux) you can use that. Here is examples of how to install the regular terminal based client (svn) with apt and pacman:
# apt-get install svn
# pacman -S svn
Connect to server
Depending if there is one or many repositories (see Server Configure), use the following commands:
For one repository used (svnserve pointing at one directory):
# svn co svn://yourhost:3690 mountDirectory
For several repositories/projects used:
# svn co svn://yourhost:3690/share/*/svn/repos1 mountDirectoryRepos1 # svn co svn://yourhost:3690/share/*/svn/repos2 mountDirectoryRepos2
Local update (download all changes):
# svn up
Server update (upload all changes):
# svn ci <file/folder>
Email Notification on SVN Activities
In order to get email notifications on SVN activities some additional work is required.
Primary dependency is getting perl installed.
ipkg install perl ipkg install perl-yaml-syck
Check if you have CPAN installed (or see below on how to install) it is necessary to configure perl to build on your hard drive and not ramdisk.
Edit the Config.pm file using nano or vi and change the path.
Ensure that the settings are as indicated below.
Use HD0_0 if using a single disk or MD0_0 if on RAID.
'build_dir' => q[/share/MD0_DATA/.cpan/build], 'cpan_home' => q[/mnt/MD0_DATA/.cpan/build], 'build_dir' => q[/share/MD0_DATA/.cpan/build], 'cpan_home' => q[/mnt/MD0_DATA/.cpan/build], 'histfile' => q[/mnt/MD0_DATA/.cpan/histfile], 'keep_source_where' => q[/mnt/MD0_DATA/.cpan/sources], 'keep_source_where' => q[/mnt/MD0_DATA/.cpan/sources], 'prefs_dir' => q[/mnt/MD0_DATA/.cpan/prefs],
Make sure the folders indicated below exist (again replace HD0_0 or MD0_0 as applicable).
/share/MD0_DATA/.cpan/build /mnt/MD0_DATA/.cpan/build /share/MD0_DATA/.cpan/build /mnt/MD0_DATA/.cpan/build /mnt/MD0_DATA/.cpan/histfile /mnt/MD0_DATA/.cpan/sources /mnt/MD0_DATA/.cpan/sources /mnt/MD0_DATA/.cpan/prefs
One option to get email notification going is to setup commit-perl script (google on this).
Then to use SVN-Notify - a Perl module that is capable of producing much richer emails.
If you don't have it installed (as I didn't), then it can be as simple as typing:
perl -MCPAN -e 'install CPAN' perl -MCPAN -e 'install YAML' perl -MCPAN -e 'install SVN::Notify' perl -MCPAN -e 'install HTML::Entities'
See http://www.cpan.org/misc/cpan-faq.html#How_install_Perl_modules for more details.
Check that it works by typing "svnnotify" at the terminal. You should be prompted for more arguments:
Missing required "--repos-path" parameter
With that installed, the next step is to replace the existing call to commit-email.pl with a call to svnnotify:
svnnotify --repos-path "$1" --revision "$2" --to firstname.lastname@example.org --from email@example.com
The arguments are fairly self explanatory. You just need to replace the values for the --to and --from arguments. A whole host of further argument options are detailed in the documentation. You may, for example, wish to use a particular smtp server rather than relying on sendmail being installed and accessible on the SVN server.
Or if like me, you like to see who committed the fix by the email address it came from, you can replace the --from argument with the --user-domain argument. The email notifications will subsequently come from the given user that committed the fix @ the given domain (e.g. firstname.lastname@example.org).
svnnotify --repos-path "$1" --revision "$2" --to email@example.com --user-domain example.org
The emails you receive with the previous command are fairly similar to the ones received via the commit-email.pl. In order to receive colorized html emails complete with diffs you need to add a couple of arguments:
svnnotify --repos-path "$1" --revision "$2" --to firstname.lastname@example.org --from email@example.com --handler HTML:ColorDiff -d
There are further options when you use this email as detailed in the SVN::Notify::HTML and SVN:Notify::HTML::ColorDiff documentation. For example, you can provide a css url if the default styling of the email isn't to your liking.