Re: what permissions are needed to let a php script call the "svn update" subversion command?

On Dec 11, 9:47 pm, Jake Barnes <lkrub...@xxxxxxxxxxxxx> wrote:
If I log into my server as root, I can easily run this line:

/usr/bin/svn update /home/www/contentingester  --username lkrubner --
password xxxxxxxx

But when I put it in a PHP script  this does not work (and by that
mean, the command "svn update" seems to never be called):

$results =  shell_exec("/usr/bin/svn update /home/www/contentingester
--username lkrubner --password
xxxxxxxx");

        echo "
                <pre>
                        The results:

                        $results
                </pre>
        ";

Is this likely a permission issues? Or a path issue? Or is there some
reason I just can't call this through shell_exec()?

There are no errors about this in the PHP error log.

I assumed this was a permissions issue, but I can't quite figure out
the right permissions. I chmoded everything in the working copy to
0777, but that didn't help. Then I chmoded /usr/bin/svn to 0777. Still
it doesn't work.

Just to be very, very clear, I mean the PHP script runs but shell_exec
seems to not work. If I put this script file on the server in a place
that can be accessed
from the web, and If I then point my browser at it, then I can see the
words "the results" but the variable $results is empty. More so, if I
look at the files that were suppose to be updated, I can see that the
"svn update" command never run. If, at that point, I log into the
server as root and run this line:

/usr/bin/svn update /home/www/contentingester --username lkrubner --
password xxxxxxxx

then the files under version control are correctly updated. But when I
try to trigger that same command using shell_exec(), it is as if "svn
update" never runs.

Background info that you probably don't need to know:

In the past (circa 2006), we had trouble getting our graphic designers
to commit their work to Subversion. They kept forgetting, and they did
not see the point. Also, we had terrible problems with FTP. 3 or 4
people would edit the same file at the same time, then upload the
file, and the last one who uploaded the file overwrote the work of
everyone else. We had ridiculous cases where someone would send an
email saying "No one is allowed to work on header.php right now. I am
working on it." Then the rest of the team would wonder how long "right
now" was. When were others allowed to edit header.php?

We solved all those problems in 2007 by giving up on FTP and using
Subversion instead. Springloops has a nice deploy option that made
this easy (actually using ssh). The graphic designers loved it. Now,
when they wanted to upload a file to the server, they just committed
it to Subversion. A moment later, the file appeared on the server. We
no longer had the problem of people overwriting each other's work,
since Subversion caught all the conflicts.

Now we are working on a new project. For various reasons, we are using
Unfuddle instead of Springloops, for our hosted Subversion needs.
Unfuddle is great in many ways, but it does not offer the easy deploy
option that Springloops offers. So we are trying to recreate this
using PHP. Unfuddle does offer a ping service on post_commit. So we
can give Unfuddle an URL that it will call at the end of each commit.
Our thought was that the URL should point to a PHP script that runs
the above command. To make all this work, we need to checkout the site
from Subversion, to the server. Having done that, we can call "svn
update" to update the site from Subversion.

(Apologies about using Google Groups to post this. I am on the road
and away from my main computer.)



Very strange. If I just do this:

$results = shell_exec("/usr/bin/svn update");

I get this result:

Skipped '.'

So apparently PHP does have permission to run the svn update command.
Something is wrong with the syntax of what I wrote in shell_exec().
.

Relevant Pages