On Thu, Mar 29, 2012 at 9:10 AM, 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?
First, it is generally a bad idea to commit build results back to
subversion on a continuous basis, because it is next to impossible to
ever remove those objects that will be obsolete on the next build from
your repository so you'll end up with a mess in a few years. Also,
for exactly the reason you describe, it doesn't make sense to commit
them to the trunk in any case (the same concurrent commits can happen
whether jenkins does the build or not...). If you have to do it, you
should make a tag to hold the source revision snapshot and its
associated results.
--
Les Mikesell
lesmikes...@gmail.com
