On Jun 2, 2009, at 07:46, J. Bakshi wrote:
> I hope I have joined the right list to discuss with post-commit
> problem.
Yes, this is a great place to discuss hook scripts.
> I am running a clark-connect ( linux ) server ( kernel
> 2.6.18-8) with subversion
>
> `````````````````````````````````````````
> svn --version
> svn, version 1.4.6 (r28521)
> compiled Dec 31 2007, 15:01:44
> ``````````````````````````````````````
You may want to consider upgrading to a more recent version of
Subversion. The current version is 1.6.2.
> I have just decided to use the post-commit hook to automatically
> update the sites running on this server when ever there is a
> commit. and
> the problem has started. The apache server is running as
> apache:apache
> (user:group) combination. the repos have the same permission level as
> well as the folders under htdocs.
>
> To start the experiment I have created a repo with just a file called
> newfile
>
> Here is my post-commit script with 755 permission
>
> ```````````````````````````
> echo " svn post commit called "
> /usr/bin/svn up /var/www/html/POSTCOMMIT
> `````````````````````````````````````````
Maybe you just didn't show it to us, but the first line of a hook
script must be a line beginning with "#!" followed by the path to the
interpreter that should be used to run the script. For example "#!/
bin/bash".
I assume /var/www/html/POSTCOMMIT already exists, is a checkout of
your repository, and every file and directory in it is owned by
apache:apache?
> checkout, accepting the certificate permanently etc.... are the
> initial
> stages I have to do. Now after modifying a file when I wanted to
> commit
> ; it reported back as
>
> `````````````````````````````````````````````````
> Sending newfile
> svn: Commit failed (details follow):
> svn: Your file or directory 'newfile' is probably out-of-date
> svn: The version resource does not correspond to the resource
> within the
> transaction. Either the requested version resource is out of date
> (needs to be updated), or the requested version resource is newer than
> the transaction root (restart the commit).
> ``````````````````````````````````````````````````````````
Doesn't sound related to the hook script. It just sounds like your
file was out of date, a perfectly normal situation to have occur.
"svn update" should resolve it.
> So I deleted the file and updated
>
> ```````````````````````````````````````````````````
> rm newfile
> rm: remove regular file `newfile'? y
>
> [root_at_192 POSTCOMMIT]# svn up
> Restored 'newfile'
> U newfile
> ````````````````````````````````````````````````````
Removing newfile shouldn't have been necessary, but is fine if your
intention was to discard the changes you had made to newfile.
> But the newfile get the root:root permission ( as I'm logged in as
> root)
That sounds totally normal.
> . So I changed the ownership and permission as I did at the begging (
> apache:apache and permisiion 777 )
>
> After modifying the file when I tried to commit it failed :-(
>
> `````````````````````````````
> Sending newfile
> Transmitting file data .
> Committed revision 20.
>
> Warning: 'post-commit' hook failed with error output:
> svn: Working copy '/var/www/html/POSTCOMMIT' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
> details)
>
> ```````````````````````````````````
It sounds like the working copy was locked, either because an svn
command was still running on that working copy, or because one had
been running and exited or was killed unexpectedly. If the former,
wait for it to finish; if the latter, "svn cleanup" should resolve it.
> It repeated again and again even after " svn cleanup". I also
> tried
> " chmod -R 777 .svn" once more but the same error.
Please confirm: even after running "svn cleanup", running "svn
update" tells you the working copy is locked? Is this only when
running "svn update" from the hook script or also when running "svn
update" from the command line?
> If I manually execute the post-commit script; it runs perfectly well
> with the echo which I placed inside the script. I am really
> confused and
> no clue why the hook is not called properly. could any one kindly
> help
> me to fix the problem ?
You're welcome to keep the echo in there, but note that that message
will never appear to the client when Subversion runs the script as a
hook script. Hook scripts only display to the client the output that
was printed to stderr, not the output that was printed to stdout like
your echo, and they only do this if the hook script exits with a non-
zero code.
Note also that hook scripts run in an empty environment. When you
manually execute the hook script, it inherits the environment (PATH,
etc.) from your shell and is thus not necessarily a good test. You
can get closer by running the hook script through the env command to
clear the environment:
env -i ./post-commit /path/to/repo $REV
Note also that when you run the hook manually, it is running as your
user, and in particular, a Subversion command running in the hook
script is looking in your user's .subversion directory for settings,
authentication caches, and so forth. When run as a hook script, it's
running, in your case, as the apache user, so it's looking for
a .subversion directory belonging to the apache user. One may not
exist. If your apache user doesn't have a login shell (it usually
doesn't) it may not even be possible for one to exist. You may need
to tell the svn command to look at a specific config directory using
the --config-dir option.
Finally, you will want to know if an error occurs while running the
svn up command. To facilitate this, I suggest you modify your "svn
up" line as follows:
/usr/bin/svn up /var/www/html/POSTCOMMIT || exit $?
This way, if "svn up" fails, the hook script will exit with the exit
code of svn, and since svn will have printed something to stderr, you
will see this message on the client.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2358922
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-03 00:14:12 CEST