2011/4/13 Peter@locotel <p...@locotel.gr> > > Thank u for your answer, > I completely appreciate all your points referring to the proper use of > subversion. > The issue is that svn is not adapted to support web applications that live > under > web-servers.
It works perfectly fine for this, provided you use it properly. >You have to export from repository to the web directory every so > often to update the operational site (no checkin). This is no different from any other version control system. You aren't required to export, you can use a working copy and run svn update. > Also web-applications can easily > live, be developed and tested on developers workstations. They should be. Developers should have a complete runtime environment on their desktop for coding, testing & debugging before committing code to the repository. > I found that having a WC being the same as /var/www/wc was unproductive as a > lot > of the svn files were deleted by the developers during debugging. So I had > to resort > to a way of managing revisions centrally and allow for a loose development > management > depending on individual preferences. It is another way of thinking about it. It sounds like your issues are not with the software, but with your developers' behavior and your process/workflow. If you enforce strong access controls (random developers can't change code on the web server) and a solid process for promoting code from the developer's unit test environment up through production, Subversion works quite well. If you leave everything wide open, or try to do things in a way that's counter to Subversion's design, you will have trouble.
