I’m going to rework how the Trac and Development sites are set up. The main problem I believe is that I need to have all of the development sites on the same user to save time from having to download the contents and then upload them to the Subversion/Trac user. It would be a solution and keep the main web sites stable while the development sites are worked on, keeping the main development only down for the time it takes to upload the new stable one. Again this would require downloading and uploading from the Trac/Subversion user to the user hosting the main site.
trac.domain.com – Trac site with index.fcgi, admin.fcgi, and .htaccess for log in hack and redirect.
svn.domain.com
Development site for which to test the site and move the contents to the repository every day or so. A perl script could be made to only move the files that were changed to the repository, if Subversion doesn’t work well with each file being moved each time. I do wonder if it is possible to set the repository up on the domain and then still be able to test it from the browser which would allow for direct editing of the repository and keep the repository updated every time.
Or
I could build a hook script that moves the file to the svn.domain.com directory whenever a file is checked in after being edited in the repository which would be the direct opposite of the other method. It would keep both the repository and the site up to date and allow the change to be tested on the live site. I will try this method first for each of the subversion repositories and see what needs to be done to build a ‘hook’ to updating the live site whenever the repository file is edited and checked in. This method would allow for a changelog to be accurate and only update the files that were changed. If this method doesn’t give good enough results then the first method will be used.
Conclusion
Right now all of the Trac files are on the one domain, but I’m going to expire the domain when I use the svn. and trac. instead. I think that once everything is done and working, I’m going to leave it alone and let it work for me. The only problem I can see is setting up users for the other repository developers to access and edit their game files. I’ve been using the shell to work with the repository and haven’t done the research required to set up access from outside the shell for people to work on the repository. It would be a required step and one I’m not looking forward to.
Possibly Related Posts:
- Calibre Improvements
- DragonU Bug Tracker Dev – Milestone 1
- Dragon MVC
- Why I Contributed to WordPress
- DragonU DB Component
Comments are closed.