Not strictly a Jenkins answer, but I would just be wary of committing executables to SVN. Remember that SVN is designed and optimised to handle source code. Sure it can handle binaries as well, but you are not going to get great compression. For a few small binaries this isn't much or a problem, but you might find you get issues adding larger exe files. It's not as if SVN gives you a way to remove old version of the file from the database.
Now if you add a CI server into the equation and get it to automatically commit these files... expect your SVN database to grow large very quickly. Personally I'd: 1) add a post build step into Jenkins and have it copy the exe to a file server. You can remove them if the server starts to run out of disc space. 2) Get Jenkins to create an SVN tag for each of your (important?) builds. This is a really light operation, so it shouldn't cause any problems. You can always recreate the build if you delete the exe and later find you need it. 3) Archive any exe's that are delivered externally. That's always worked for me, but your situation might be different. On Thu, Mar 29, 2012 at 3:10 PM, shanz <duncan.perr...@gmail.com> wrote: > This is a subversion question rather than a Jenkins one I suppose. > Our build on Jenkins takes several hours. Assume the build begins > with svn revision 700. > If someone commits to Jenkins' trunk (making revision 701) during > those build hours, then the resultant executable is out-of-step with > the repository. We want to commit the resultant exe. So the exe will > be on revision 702 but the exe wasn't built with the features > introduced with revision 701. > > Is this a common problem? Any solutions?
