On Fri, Apr 11, 2008 at 8:34 AM, Laker Netman <laker_netman_at_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:
> The reason for setting things up with three repos is mostly based on
> legacy file arrangements prior to moving into Subversion. (Those were ugly
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.
Received on 2008-04-11 17:59:26 CEST