CODEWITHSUNDEEP
svn
Doug Wolfgram
Doug Wolfgram

Reputation: 2126

Remove deleted from from svn working copy directory

My svn repo is /home/httpd/svn/project. The working copy is /home/httpd/svn/project_work. I am running a post-commit script that updates the working copy, then rsyncs with the test site. This works fine.

But I need to remove deleted files from the working copy directory as well. I know this this script works if I am currently in my working copy directory:

svn status | grep '^!' | sed 's/! *//' | xargs -I% svn rm %

But my post-script is running in the svn/hooks directory. How to I tell the above command to operate on the files in the working copy directory so that it can be part of my post-commit script?

My script looks like this:

$SVN update $HOST/$SITE_WORK --non-interactive --username xxxxx --password xxxx >> $LOG
$RSYNC -azv --exclude=.svn $HOST/$SITE_WORK/* /home/httpd/sites/$SITEDIR/doc-root >> $LOG

Upvotes: 0

Views: 2032

Answers (2)

David W.
David W.

Reputation: 107080

I'm going to recommend you take a look at Jenkins. Jenkins is a continuous build system, but it also is great for doing just this type of task.

What I would recommend is a bit different from what you're doing -- especially if you are talking about httpd:

  • Do an svn export to a new working directory. This is clean, and doesn't include the .svn directories (although SVN 1.7 doesn't plaster them everywhere as earlier versions did).
  • Once the export is complete, rename the old working directory to a temporary name.
  • Rename the new working directory with the name of the old working directory.
  • Delete the old working directory.

This will prevent your working directory from being in an inconsistent state where old and new versions of the files exist at the same time in the same directory tree. Plus, this is self recovering. If for some reason the old update doesn't complete, a new build will put everything just right once again.

By using Jenkins to do this whenever it detects a new Subversion release, you no longer need the post-commit hook. The problem is that while that post-commit hook is running, your user has to sit at their desk twiddling their thumbs waiting for Subversion to pass a nay or yea on the post-commit work. Plus, you can always hit the rebuild button to rebuild the working directory in case there is a problem.

Here's how it will work:

  • User commits their changes. There is no post-commit hook. User sees immediately whether or not their changes are good.
  • Jenkins sees the changes, and does a svn export on the server to create a new working directory.
  • Jenkins detects that the svn export is successful, and then moves the old working directory to another name, renames the new working directory to the old location, and then (optionally) deletes the old working copy. There is never a time that the old working directory is in an inconsistent state.
  • Jenkins can send an email when the change takes place. Jenkins might also run some smoke testing to see if the code checked in is good, and not do an update if it detects a problem.

Upvotes: 1

Andreas Wederbrand
Andreas Wederbrand

Reputation: 40061

It is not possible for the SVN server to send commands to be executed on the client. You could alias svn on each client to both run svn and a custom script if you wish.

Also, files deleted with svn rm <filename> are deleted on all clients when they do svn up.

From your script I see that you find all status lines starting with ! which indicates that you've made changes to your working copy without using svn. From the manual

'!'
Item is missing (e.g. you moved or deleted it without using svn). This also indicates that a directory is incomplete (a checkout or update was interrupted).

It sounds like you or your users are doing something wrong.

Edit: this is a transcript of a test session about deleting files:

I've checked out a repository into two working copies, they are called sof and sof2 on my disk.
On sof I've added aFile.txt and commited it. On sof2 I've just checked out that file. This is how it looks now:

$ svn info aFile.txt 
Path: aFile.txt
Name: aFile.txt
URL: http://xp-dev.com/svn/sof/trunk/aFile.txt
Repository Root: http://xp-dev.com/svn/sof
Repository UUID: d3d45886-b759-4dae-a297-3c88720da0c3
Revision: 2
Node Kind: file
Schedule: normal
Last Changed Author: wederbrand
Last Changed Rev: 2
Last Changed Date: 2011-12-05 19:53:11 +0100 (Mon, 05 Dec 2011)
Text Last Updated: 2011-12-05 19:53:37 +0100 (Mon, 05 Dec 2011)
Checksum: e5bc1e83330bccc8efe0e884b79a1c43

Now I'll delete it on sof

$svn rm aFile.txt 
D         aFile.txt
$ svn commit -m'file deleted'
Deleting       trunk/aFile.txt

Committed revision 3.
$ l
<no files left in directory>
$ svn info aFile.txt
aFile.txt:  (Not a versioned resource)

and the file is gone, now to sof2 where I'm about to get the latest updates

$ l
total 8
-rw-r--r--  1 raven  staff  36 Dec  5 19:53 aFile.txt
$ svn up
D    aFile.txt
Updated to revision 3.
$ l
<no files shown, it has been deleted>

If you get any other behavior than this stuff are really weird :)

Upvotes: 1

Related Questions