I think I've come to a decision. I will try and continue to use the Check-out Strategy, "Emulate clean checkout..." since it is a nice way to delete unversioned files which could be tricky otherwise. I will encapsulate the Emulate clean checkout in a separate 'function' job. The initial job will call svn switch and svn revert before triggering the Emulate clean checkout.
On Tuesday, April 17, 2012 11:07:05 AM UTC+1, shanz 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? > > >
