Differentiating post-commit working copy updates

[Laker Netman <la...@yahoo.com>]

Currently (in abstract terms) I have three repositories Alpha, Beta, Live for website production work. Each repository has a working copy that is a web site document root for the respective repo. Alpha contains files that are, on the whole, incompatible with Beta or Live. Beta is simply a staging area for files being moved to Live, for final review. There is a post-commit script for each repo that copies whatever is committed from me to the trunk is then copied to the associated web doc root, ala:http://subversion.tigris.org/faq.html#website-auto-update

The reason for setting things up with three repos is mostly based on legacy file arrangements prior to moving into Subversion. (Those were ugly days...)

I would like to fold at least two (possibly all three) of these repos into one, but I haven't gotten my head around that yet. I'm thinking Alpha branch/Beta trunk or Beta branch/Live trunk. But, while I know it's feasible, is an Alpha branch/Beta branch/Live trunk practical?

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. From what I've read in the svn-book and after googling, it looks like it's not possible for the post-commit script to determine whether a commit is being made to a particular branch or the trunk of a given repo.  Is this true?  If it's possible (but not yet implemented), has there been any discussion of adding another environment variable to help a script identify where a commit is being made to within a repo?


Thanks,
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Differentiating post-commit working copy updates

[Hari Kodungallur <hk...@gmail.com>]

On Fri, Apr 11, 2008 at 8:34 AM, Laker Netman <la...@yahoo.com>
wrote:

> Currently (in abstract terms) I have three repositories Alpha, Beta, Live
> for website production work. Each repository has a working copy that is a
> web site document root for the respective repo. Alpha contains files that
> are, on the whole, incompatible with Beta or Live. Beta is simply a staging
> area for files being moved to Live, for final review. There is a post-commit
> script for each repo that copies whatever is committed from me to the trunk
> is then copied to the associated web doc root, ala:
> http://subversion.tigris.org/faq.html#website-auto-update
>
> The reason for setting things up with three repos is mostly based on
> legacy file arrangements prior to moving into Subversion. (Those were ugly
> days...)



When you moved the repositories to Subversion, that was the perfect
opportunity to move away from legacy stuff as well...


>
>
> I would like to fold at least two (possibly all three) of these repos into
> one, but I haven't gotten my head around that yet. I'm thinking Alpha
> branch/Beta trunk or Beta branch/Live trunk. But, while I know it's
> feasible, is an Alpha branch/Beta branch/Live trunk practical?


In the long run, I think this is not a practical solution.



>
>
> 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. From what I've read in the svn-book and after googling, it looks like
> it's not possible for the post-commit script to determine whether a commit
> is being made to a particular branch or the trunk of a given repo.  Is this
> true?  If it's possible (but not yet implemented), has there been any
> discussion of adding another environment variable to help a script identify
> where a commit is being made to within a repo?



It is not true that the hooks can't identify the files committed to the
repo. The hooks are provided with two arguments, the repository path and the
revision number. You can use these two with the 'svnlook' or 'svn' commands
and get almost any information (including the filenames, with full path,
that changed for that revision) that you want.


rgds,
-Hari

Re: Differentiating post-commit working copy updates

[John Peacock <jo...@havurah-software.org>]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org