Re: Hooks

Okay, you want to mirror all the repositories. Take a look at svnsync
which comes with Subversion. Svnsync creates read only mirrors of the
original repository. That's a lot simpler than attempting to do this
with hook scripts. Although, you could call svnsync in a post-hook
script if you so desire.

A good question is why do you have multiple repositories? The test and
production people really don't need the entire repository, just the
approved revisions/builds. For example, you might have 100 revisions
in your development Subversion repository, but only send 20 of those
to test. In turn, test might only send 3 of those 20 to production to
actually install.

What you really want is a way to store builds that should be promoted.
Version control systems aren't really made to be release repositories.

--
David Weintraub
qazwart_at_gmail.com
On Fri, Oct 17, 2008 at 7:36 PM, Ravi Gehlot <ravi_at_ravigehlot.net> wrote:
> Hi David,
>
>   First of all, thanks for helping. This question was actually originated by
> my friend Eric Roberts. I also do not know how to fix this problem. But here
> is a scenario: Let's say that we have 2 servers and both servers have
> different IPs under the same subnet which makes them members of the same
> network. Let's imply that we have SVN-Server installed in both
> server-machines and that one of them is a DEV server and the other is a TEST
> Server. How can I program my hook so that it commits across that same
> network from IP1 to IP2 meaning from Server 1 to Server 2? I could be wrong
> but it looks like hooks only work with the local protocol file:/// so how
> would I commit to a directory found in another machine instead of some local
> directory on the same machine?
>
> Ravi.
>
> David Weintraub wrote:
>>
>> On Fri, Oct 17, 2008 at 5:15 PM, Ravi Gehlot <ravi_at_ravigehlot.net> wrote:
>>
>>>
>>> Can I use hooks to invoke an update when there is a commit on a
>>> repostiory
>>> when the code and repo are on differnt servers (same network)?
>>>
>>
>> A post-commit hook can be made to do just that. There has been several
>> discussions on this very list about that type of hook. An easy way is
>> to have the post-commit hook pass the svn update command as an
>> argument to the "ssh" command. There are a few gotchas you do have to
>> watch for:
>>
>> * Subversion doesn't complete the commit until the post-commit hook is
>> done. Actually, the commit is completed, but the user doesn't have any
>> way of knowing that because their command line client is waiting for
>> the post-commit hook to return. To get around this issue, put the
>> actual update in background in side the hook. That way, the user
>> doesn't have to wait for the hook to complete.
>>
>> * You don't want to update a live webpage because at some point it
>> will be unstable with 1/2 of the files being updated, and the other
>> half being obsolete.  A recommended strategy is to have your Apache
>> root as a symbolic link pointing to the directory that contains the
>> web content. You do a "svn export" to a new directory, then change the
>> symbolic link to point to that directory.
>>
>> Personally, I am a bit weary about auto-updating webpages on every
>> commit. My preference is to put the actual web page on a branch.
>> Updating the trunk doesn't update the webpage, but allows you to do
>> packaging and testing. Maybe the latest check in is not a good idea.
>> After testing, you can post to the web-page branch which will update
>> the webpage.
>>
>> This way, you have a bit more control over the webpage updates. I use
>> to do the updates via a crontab instead of using the post-commit
>> update hook. I would have the crontab run at a particular time during
>> the day. This allowed me to take down the website for maintenance
>> before I did the update, and made sure I didn't confuse any of my
>> users.
>>
>> --
>> David Weintraub
>> qazwart_at_gmail.com
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org