views:

35

answers:

4

I basically want to do an SVN export as part of a scripted build process, but without having to get the entire repo from scratch every time, which is slow and eats bandwidth... not to mention will make testing the script a pain in the backside if it does this everytime we tweak something or spot a typo in the scripts.

Is there an obvious way to do an export into an existing directory, so only files that are different are fetched, and non-repo files are deleted, basically giving a clean export but done in a smart way?

Windows is preferred, but I guess Cygwin is an option.

+2  A: 

I think the only way to get this done, is to checkout a working copy, and update & revert that. Updating a WC only gets the changes.

svn export doesn't know what files are changed, and to compare files, you first have to fetch all of them. Also it would be hard to get files that were deleted or renamed out of your 'export' directory.

Sander Rijken
+1  A: 

Checkout a working copy, then export from your working copy. SVN update on the working copy will then be quick and bandwitch light. Then you can delete the original export and re-export from the working copy.

All the bandwidth hungry operations are optimized. The heavy handed delete and re-create is the same as it was before, but it's now all local, so should be much faster.

Also, you have the option to make changes in the exported working copy, but you might want to be careful with that and consider the impact of having conflicts occur during your svn update.

Jim T
Will the export from the local WC only consider SVN files, or if something else gets in the WC will that get copied too?
John
the export command will only look at files actually under svn's control and ignore everything else.
Jim T
A: 

I am not sure if I understand your question right. To rephrase it. I think you would want to have the repo local copy updated on a regular basis. However you would want the working copy pristine so that the resulting build is a clean. Considering this is your question below is what I would suggest.

To my knowledge svn export might not be the be best option for this. Because the purpose of svn export is to obtain a unversioned working copy of the svn repo. As it is unversioned, svn client would not really know from where it has to start the update.

The best option i can think of is this. Checkout the copy of the repo (local copy, LC) in a location. This LC should be updated during the build process. Make a copy of the LC in a different location and use it for performing the build. Below are the commands you would require

1. svn update <arbitrary path>(in the working copy)
2. copy <arbitrary path> <build path>
3. find <build path> -type 'd' -name '.svn' (if you would like to remove the .svn hidden files, but they are not going to really hurt the build process)

Some Options for Eliminating the copy time from factoring in the build process time

  1. If you would like to save the copy time during the build process probably you can do this copy operation after each build and svn update the copy just before building (assume the .svn folders are retained).

  2. On linux two folders can be kept in sync using rsync. The build copy can be made to reflect the updates in the pristine copy.

  3. In Windows, there are a few tools to achieve sync suggested above. I have not used them but I will provide you the links to try it yourself.
    http://lifehacker.com/326199/synchronize-folders-with-synctoy-20 http://www.techsupportalert.com/best-free-folder-synchronization-utility.htm

Version Control Buddy
A: 

Another option is to use checkout and revert / update but also use something like the SharpSvn library to make a script that will delete non-source controlled files. This way build artifacts like compiled code will be removed and the versioned files will be returned to base state by the revert / update.

If you have a lot of directories and files this scanning could be slow, but if you are confident about what directories will contain build artifacts would can just scan those.

Amasuriel