Comments on: Using Subversion to version control websites http://povich.co.uk/blog/2008/03/using-subversion-to-version-control-websites/ Ramblings of Jim Whiteside, and some good old Norfolk squit. Tue, 07 Sep 2010 09:59:51 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: » PHP ob_gziphandler “Content Encoding Error” | Povich - Jim Whiteside spouting squit http://povich.co.uk/blog/2008/03/using-subversion-to-version-control-websites/comment-page-1/#comment-155 » PHP ob_gziphandler “Content Encoding Error” | Povich - Jim Whiteside spouting squit Wed, 17 Dec 2008 14:56:21 +0000 http://povich.co.uk/blog/?p=137#comment-155 [...] configuration include called at the start of each page that’s not under version control (for obvious reasons), and on this server it somehow acquired a couple of line breaks at the end after the closing php [...] [...] configuration include called at the start of each page that’s not under version control (for obvious reasons), and on this server it somehow acquired a couple of line breaks at the end after the closing php [...]

]]> By: mat http://povich.co.uk/blog/2008/03/using-subversion-to-version-control-websites/comment-page-1/#comment-134 mat Sun, 16 Mar 2008 16:23:16 +0000 http://povich.co.uk/blog/?p=137#comment-134 I've been using darcs for version control. The nice bit about darcs over svn is that it uses a 'patches' system to manage changes. Which means when I have local stuff that's different between versions (like ftp root, etc), all I do is run 'darcs record' immediately after making the localisation changes, then just never push that 'local changes' patch to other instances of the repository. It's worked for the last couple of years without problems - I haven't used svn much so I can't really compare them, but darcs conflict resolution is pretty neat, and I've never ended up breaking mbUK live while pushing changes from the testing repository. Another handy thing I picked up (off Ben) was to create a folder with all the server config files in (ie, apache's conf, etc), then symlink from /etc/apache2/sites-available/mysite --> /home/myuser/site/config/apacheconf, where ~/site is under version control. Useful if you have non-standard server configs. If you want to version control database schema, it's but the work of a moment to create a script that mysqldump's your DB structure to a file, which can then be version controlled. But then you know that. :) Have you come across <a href="http://trac.edgewall.org/" rel="nofollow">Trac</a> at all? Really nice bit of software project management software. Nice ticketing system, and you can hook it up to your SVN or Darcs repository too. I’ve been using darcs for version control. The nice bit about darcs over svn is that it uses a ‘patches’ system to manage changes. Which means when I have local stuff that’s different between versions (like ftp root, etc), all I do is run ‘darcs record’ immediately after making the localisation changes, then just never push that ‘local changes’ patch to other instances of the repository. It’s worked for the last couple of years without problems - I haven’t used svn much so I can’t really compare them, but darcs conflict resolution is pretty neat, and I’ve never ended up breaking mbUK live while pushing changes from the testing repository.

Another handy thing I picked up (off Ben) was to create a folder with all the server config files in (ie, apache’s conf, etc), then symlink from /etc/apache2/sites-available/mysite –> /home/myuser/site/config/apacheconf, where ~/site is under version control. Useful if you have non-standard server configs.

If you want to version control database schema, it’s but the work of a moment to create a script that mysqldump’s your DB structure to a file, which can then be version controlled. But then you know that. :)

Have you come across Trac at all? Really nice bit of software project management software. Nice ticketing system, and you can hook it up to your SVN or Darcs repository too.

]]>