[pmwiki-users] Subversion & existing installation

Joachim Durchholz jo at durchholz.org
Mon Dec 12 17:01:56 CST 2005


Patrick R. Michaud schrieb:
> On Mon, Dec 12, 2005 at 01:04:40PM -0700, H. Fox wrote:
> 
>>On 12/1/05, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>>
>>I installed Subversion over the weekend and discovered an easy way to do it.
>>
>>    svn export svn://pmwiki.org/pmwiki/tags/latest pmwiki --force
> 
> Oh.  I had tried "--force" but it didn't work for me for some reason --
> maybe I didn't have it in the correct place.

See below for a working incantation.

>>For those two reasons, I think  `export' is much closer to what nearly
>>all administrators would want.
> 
> I totally agree, and will change the PmWiki.Subversion instructions
> to match.

For a different project, I have a script like that proposed by Hagan in 
the post-commit hook. I use that to set up the test-drive installation 
of the software, but it's of course also useful to publish a 
bleeding-edge installation package.

I.e. in

   /srv/svn/repositories/<project_name>/hooks/post-commit

I have

   #!/bin/sh
   # Get the parameters.
   # Not really necessary because all the paths are hardcoded,
   # but useful for logging purposes.
   REPOSITORY="$1"
   REV="$2"
   # Debug output. Also, I like to have a verbose log.
   logger "svnserve: Post-committing rev. $2 to $REPOSITORY"
   # This one is needed to get rwxrwxr-x permissions on
   # directories and (without the x) files created.
   # You need the second rwx to make the files/directories
   # group writable, which is necessary in common (rather
   # unsafe) mod_php setups.
   # If you don't need it, you can say "umask 022" instead;
   # this is usually the default, so it's even possible to
   # leave that command out entirely.
   umask 002
   # Change to the directory where things should go.
   cd /home/htdocs/web1/html
   # This one tends to be necessary if your file names contain
   # "funny characters" like äöüß.
   export LC_CTYPE=en_US.UTF-8
   # Run the export command, capture the output.
   # If you don't want to capture the output,
   # just use the command between the backticks (`).
   out=`svn export --non-interactive --force --quiet \
       file:///srv/svn/repositories/<project_name> . 2>&1"`
   # Logging the stuff. It would be better if each line of svn output
   # got its separate log line, but I was too lazy for that :-)
   logger "$out"
   # Debug output. Also, I like to have a verbose log.
   logger "svnserve: Post-commit of rev. $2 to $REPOSITORY done"

Fine points:

1) --non-interactive prevents the thing fom asking questions.
2) --force will overwrite in place. However, I don't think it deletes 
files. It's probably a better idea to do an rm -rf on the directory 
before exporting to it - and in that case, you don't need --force 
anyway. I haven't investigated that fully though, and the test drive 
installation I'm feeding with that script isn't picky about superfluous 
files.
3) --quiet makes svn silent about the list of files exported (which 
isn't very interesting in that context anyway). This means that I won't 
get anything but error messages in the log.
4) This script is using logger, which means logging to the system's log. 
That's appropriate for me since I'm administrating the machine anyway 
(and the initial reason for logging was debugging the script). In 
practice, you'd probably want to do something like
   svn export ... >>/path/to/log/file
The log file could be put into your home directory. (Putting it into the 
target directory would be an options, but then you won't get a message 
if writing to the directory failed. So log to a known writable file 
while you're setting the script up.)
5) If your script has many commands that might emit error messages, 
appending >>/path/to/log/file might become unwieldy. I'd split the thing 
into two scripts, a wrapper that does the logging (with a 2>&1 that 
redirects error output to stdout), and a worker script that does the 
actual calls to svn and whatever; there might be better ways but I'm not 
aware of them.

HTH
Jo




More information about the pmwiki-users mailing list