I have discarded the idea of an emulated clean checkout completely. I used it in the beginning for all jobs until a non-critical showed a bad behaviour. The files weren't updated reliable. It was a job for creating release notes. Later did we have the same issue with a build job were committed changes have not been applied at build time.
So I used it from the point only for non-critical jobs. But I did also discard it there as I occassionally had broken builds as the emulation did mess up the workspace until a conflict occurred that had to be fixed manually. Only kind of jobs that still use the emulation are the continous build jobs as they just compile the dependencies. If the error occurs here it will "heal" itself after a certain amount of builds as the workspace normally doesn't break.I had it once or twice in more than a year that I had to intervene here. The idea is nice but prone to errors (some also caused by human beings). I have decided to sacrifice a few minutes more of build time for a completely new checkout at each build. That gives me the content feeling of having a proper workspace :) And I don't have to crunch on issues likes yours anymore. On Apr 17, 12:07 pm, shanz <duncan.perr...@gmail.com> wrote: > I am using the svn check-out strategy - "Emulate clean checkout by first > deleting unversioned/ignored files, then 'svn update'". > > Before this Emulated Checkout Job is called it is unsafe to assume the > location of the working copy folder is known. > So the working copy could be be pointing to (possibly out of date) trunk, a > branch or a tag. > > This leads me to want to use an 'svn switch' command to ensure that the > working copy points the trunk before calling the Emulated Checkout Job. > 'svn switch' automatically calls svn update so it would seem to result in > calling 'svn update' once, then deleting unversioned/ignored files then > calling svn update a second time. > > What happens if I setup branch-based urls in the Check-out Strategy's > Subversion Modules Repository URL but the Local module directory is > pointing to a working copy that already points to the trunk? > Does the svn update cope even though it should really be an svn switch? > > How does everyone else use svn switch and the svn check-out strategy?
