----- Original Message ----
From: John Peacock <john.peacock_at_havurah-software.org>
To: Laker Netman <laker_netman_at_yahoo.com>
Cc: users_at_subversion.tigris.org
Sent: Friday, April 11, 2008 11:44:52 AM
Subject: Re: Differentiating post-commit working copy updates
Laker Netman wrote:
> Currently (in abstract terms) I have three repositories Alpha, Beta,
> Live for website production work.
Yeah, this isn't a very good architecture. You have no way of moving
things from one stream to another *and* knowing where it came from. You
are just randomly throwing bits of code over the wall and (if you aren't
documenting extremely well with the log entry) you have no idea where it
came from.
> In a perfect world, I want to move Alpha branch commits manually to
> the Beta branch, and Beta branch commits automatically to Live,
> keeping the post-commit functionality working that has the web
> server-side auto update its working copy of any branch. That's where
> I think things might fall apart.
Not at all, this is a well supported mode of operation. The post-commit
hook has enough information to determine where the file[s] were
committed in the repo and act on that information accordingly.
I wrote a Perl module called SVN::Notify::Mirror[1] to handle precisely
this sort of model and it works quite well (especially with
SVN::Notify::Config[2] which I did not write but have taken over
maintaining). A simple to read config file acts as your post-commit
script and can fire whatever rules you want to update an arbitrary
number of web servers via SSH or rsync (I may add FTP someday).
You can read the documentation of my module for more details, but the
crux of it is that I recommend the following repository structure:
site
/trunk
/branches
/tags
(in case you have more than one site). 'site/trunk' corresponds to what
you are referring to as Beta (those changes which will be definitely
moved into production after testing). 'site/tags' is where the Live
server will pull its files from. And 'site/branches' is your Alpha
(where speculative development happens). The developers don't have to
touch either the test or production servers: the post-commit hook does
the right thing.
Normal development happens on trunk (i.e. the developers usually only
have trunk checked out). Any commit to trunk is automatically updated
(via your post-commit hook) to the Test server, for testing (obviously). ;-)
When code is stable and you want to move it into production, you create
a tag based on trunk, which will automatically be promoted to the
Production server, using that same post-commit script. The production
server will always be running a consistent set of files that corresponds
to a specific tag, so it is easy to roll back "brown bag" releases to
the previous tag.
Speculative (Alpha) changes are made on feature branches (one branch per
feature) and merged to trunk if they are something you want to use (or
deleted if they arent). Then you follow the test/tag model to move
those changes into production.
HTH
John
1) http://search.cpan.org/search?query=SVN::Notify::Mirror
2) http://search.cpan.org/search?query=SVN::Notify::Config
Yes, this helps immensely! The structure you outlined is exactly the layout I want to use. So, I have homework for the weekend :) Three questions before I continue down this path.
1. What is the minimum release/build of Perl that supports SVN::Notify, et al?
2. Do I install SVN::Notify first, then add the "Mirror" and "Config" subclasses? (Sorry, I have had limited administrative exposure to Perl)
3. Does this work in an "svnserve" environment vs. Apache? Any notable differences?
Thanks again,
Laker
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-11 21:32:55 CEST