On 3 August 2011 05:47, Nico Kadel-Garcia <nka...@gmail.com> wrote: > That's what "svn checkout" for initial setup, and "svn update" or "svn > revert" of the local copy are for.
We already have that working, I just outlined the current setup: http://files.foobar.org/ is a direct file mirror (less revision control; plus additional files generated post-commit dependent on the latest version of each revision controlled file) of http://svn.foobar.org/trunk/somewhere. Developers push stuff to somewhere (which is private in Subversion). This private area then gets served as HTTP/FTP, edited appropriately for public use (and also for programs as some of the files generated after a commit are databases). > Then you do your updates in a working copy as part of a working copy, > and that copy has a deployment script or "Makefile" that does "rsync" > or other mirroring tools to publish those changes to your exposed > website. I like "Makefile" bassed approaches, myself, so I can do > "make", "make test", and "make install". Ahh yes. This was one of our earlier plans, but I scraped that because it would duplicate the contents (of the SVN repo) on the server. But let me get this right: svn commit (anywhere) -> post-commit -> svn up (local checkout), rsync -> local mirror -> edits ? -- GPG/PGP ID: 19BAA7AD
