[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion transactions within post-commit

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Tue, 2 Aug 2011 23:26:52 -0400

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
> 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 ?

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.