Implementing Subversion for small webdesign team
Hi all, This is my first post here, although i've been around this forum for quite some time now. Im trying to implement subversion on a small webdesign studio, where we are responsible for 200+ websites, most of them with PHP based content management systems. Im quite sure of the benefits of subversion, but for some time now i've been struggling with some key concepts that we need to clarify before even think of changing our current workflow. Hoping that some of you may help, i believe that some of my problems are actually pretty common for people in my position, so here it goes. Our environment will most likely be: - local staging server for all repositories with ubuntu + subversion + warehouse - Every developer/designer has MAMP a working copies on local machines (both mac and win) - Webservers Considering this: 1) What is the best method for publishing websites? Commit hooks (how), commit and FTP, others? 2) How should we deal with user created files on public sites and avoid to deleted or modified those external info not on local repositories? We have also considered services like Beanstalk but the self hosted solution proved to be a better solution both in cost and performance. Thanks in advance for the much needed help.
Hi again, I know im probably asking for too much but right now im on a dead end, therefore any help would be much appreciated. Thanks!
kimiHi again, I know im probably asking for too much but right now im on a dead end, therefore any help would be much appreciated. Thanks!Hi Kimi, I'm by no means an expert, and I've got my own posts here that nobody's replied to but I'll at least put something in your thread :-) My understanding of SVN is as follows: With respect to customer modified files: If those files are version controlled, then either you or your customer will need to commit them to the repo to ensure that they are properly handled. If they are not version controlled - then basically nothing "bad" can happen to them: eg: 1) If you don't add a file to a repo, then it will not be version controlled and it will not go into or be deleted from your working copy when you update your working copy. It will just be ignored. 2) If you put a file into your repo and then later mark it as deleted, then it will be deleting from your working copy when you do an update. 3) If you put a file into your repo, and someone else changes it but that change is not committed to the repo - then when you update or pull out a new working copy - either: a) SVN will tell you that your working copy is out of sync and require you to commit before you update or b) SVN will overwrite the new file with the version in the repo. I'm not 100% sure under what circumstances b) will occur. The generally recognized solution to the issue where a SVN controlled file might be modified and you don't want to SVN the modification (as I read it ) is to use the template approach. This isn't a feature of SVN in as much as it's a management technique. Let's say you have a file such as website.css. You want the customer to modify website.css - but you also have a common SVN'd internal copy. Create website.css.tmp as a file and subversion that file. I assume this would be an external (read up on externals). When you start a new site and you pull out this external, rename it website.css and make your local changes. Now the website.css.tmp will NOT be overwritten by website.css because they are different file names. I am not sure about taking that external file and making it part of your version controlled source, but I think it's as simple as copying it out of the external folder and into a versioned folder thats part of the project. Hope that helps somewhat. Like I said - I'm no expert. -Rob
Hi fibbert, Im thankful that you took the time to give some input. I must confess i was hoping for a lot more feedback... The customer created files i was talking about was more like file uploads through cms and stuff like that. Configuration, php, css etc its only touched by us through the local working copies, repo, and so on. Someone told that the best thing to do, or a possible way of doing it, was not to control version those folders (uploads etc) by ignoring them. That leaves me with the live working copy update issue. Right now im considering install a post-commit on the repo (local server) which the executes trough ssh a update on the remote working copy (live website). The best article i found so far was this http://maymay.net/blog/2007/06/21/a-better-expect-subversion-post-commit-hook/. If anyone knows about a better way please let us know.
Yes, if you have SSH access to your server, then it's very simple just to update the working copy on the server using a hook script. That's a reasonable way to do it. I also agree with the advice that your user's uploads should be in a directory that's simply ignored. A couple of other things to consider: working copies currently require the use of .svn directories, so those will be sitting on your web server. It's probably not desirable to have that stuff available, so if you can prevent those from being served, such as using .htaccess in apache or something, then that would be good. Another thing: a commit won't finish until the post-commit hook script has finished. So it's best to make sure that your update script runs asynchronously. The common way of doing this is to append an ampersand to the command if you're on Unix/Linux.
Thanks (ode$linger, Yes, i do have ssh access so im hoping this will work fine. About your message:
Another thing: a commit won't finish until the post-commit hook script has finished. So it's best to make sure that your update script runs asynchronously. The common way of doing this is to append an ampersand to the command if you're on Unix/Linux.Considering that i will likely to use the following post commit script: http://maymay.net/blog/2007/06/21/a-better-expect-subversion-post-commit-hook/ Is it possible to apply your recommendation?
1-6 of 6
Reply to this discussion
You cannot edit posts or make replies: You should be logged in before you can post.