Today I worked on a project device and was busy with svn - I decided to share some tips: Automatic code upload to the server from the repository after the commit Versioning of settings files (Settings.php / xml / yml) Storage of fat and low-volatile third-party libraries in a repository with a fast project cheukut
Automatic code upload to the server from the repository after the commit the site on php also wanted that after a commit in a repository the code on a demo server was automatically updated. You can do this using svn-hooks: there is a daddy hooks in the root of each repository, into which you can put some executable (for example, the script: full / path / to / svn update path / to / web / folder) and call it a certain way ( for example, post-commit.sh or post-commit.bat) - and after each commit, this script will be executed and update the code on the demo (there may be problems with permissions to access files - read the links). At the same time, the svn service files will be laid out on the demo. This problem is solved by the apache settings: <DirectoryMatch "^/.*/\.svn/"> Order deny,allow Deny from all
How to version settings (Settings.php / xml / yml) So we have a file with the settings, it will be corrected for each machine on which your application will be installed. Therefore, each group commit from a new machine will overwrite this file in the repository, and when updating the working version on another machine, it may also be unpleasant to rewrite the settings on this machine. How to be prompted to us by subversion.tigris.org/faq.html#ignore-commit : You should copy the file with the initial settings for example settings.php in settings.template.php and add settings.php to svn: ignore. As a result, when you deploy an application, you must perform the reverse operation of copying settings.template.php in settings.php (settings.php is not in the repository) and then correct it for a specific installation. Because of svn: ignore, the settings.php file will not be committed anymore
How to store fatty third-party libraries In my case, it was a dojo (great js toolkit), which is much larger than the project itself (and practically will not change), and trying to upload it to the repository and getting back takes an unpleasantly long amount of time. Therefore, I slightly modified the previous technique to solve this problem: so we have a dojo deep folder - add it to svn: ignore - and archive it in extract_to_dojo.archiv - which we upload to the repository. When deploying in a new place, you must perform the reverse operation. In principle, to automate the deployment of a new version, you can write a small script that runs through all of /extract_to(.?)\.rar/ and unarchives them in $ 1
')
For those who have to work on the Win platform, the useful svn + apache + gui build is www.visualsvn.com