On Tue, Aug 2, 2011 at 6:49 PM, Ray Rashif <schiv_at_archaudio.org> wrote:
> On 3 August 2011 05:47, Nico Kadel-Garcia <nkadel_at_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
> 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 ?
Put it in a checklist
1: svn commit (from any authorized user)
2: post-commit publishes updates
I) Create designated working copy, if needed
II) "svn revert" in working copy, to avlid conflicting local
changes overlapping push process
iii) "svn status" in working copy, to report failures or conflicting debris
iv) "svn update" to get relevant updates
v) Edit or generate non-committed local files as needed
vi) Push working copy contents to website with some efficient tool
that does not overwrite correctly published content, such as "rsync"
vii) Leave working copy around for future updates as appropriate
Received on 2011-08-03 05:27:40 CEST