[BuildTools] Problems with commit_new_release

[Laszlo Ladanyi]

On Mon, 29 Oct 2007, Andreas Waechter wrote:

> Hi Ted,
>
>> I used the new scripts for preparing a new release of SYMPHONY this
>> morning and there seems to be a few problems with the commit_new_release
>> script. I have not spent enough time to extract all the details of what
>> happened, but wanted to throw this out there, since I know there are a
>> number of folks preparing releases right now. The first glitch I noticed
>> was that the script exited after the following error:
>> 
>> svn: 'ThirdParty/Glpk/glpk/configure.ac' is not a working copy
>> svn: Can't open file 'ThirdParty/Glpk/glpk/configure.ac/.svn/entries':
>> Not a directory
>
> This appears to be a problem with subversion.  Maybe there was a problem 
> communicating with the server...  I have seen this before myself, I think, 
> and I simply had to check out a new copy.

I think Ted is right. The failure stems from glpk having its own configure.ac 
file. It is found by the find command, then it's patched (which, as you 
correctly say below, is fine) and finally an 'svn diff configure.ac' is done 
to it. svn rightfully says that it is not a working copy, and since there was 
an error, returns a non-zero exit value, and after that the script aborts.

The simplest way to fix it is to first check whether the configure.ac file is 
managed by subversion or not.

>
>> That's when I noticed that for some reason, the script was trying to
>> change the version numbers in the configure.ac files for not only
>> SYMPHONY, but all the dependent projects. Hence, it was trying to change
>> the version numbers for the CoinUtils release version, for instance,
>> back to 5.1stable. This seems like a bug.
>
> The easiest way to change things back to "5.1stable" was to do it for all 
> configure.ac files that are found by 'find'.  You are right, this does change 
> it also on other configure scripts, but those will not be committed back to 
> the repository, so I didn't bother to make sure it is only changed in those 
> configure.ac files that correspond to the particular project. The files that 
> have been "incorrectly" changed will simply be ignored and deleted.
>
>> The other thing that went wrong is that for some reason (I was not able
>> to ascertain why because I deleted the temporary directory before
>> realizing this), the script did not succeed in restoring the externals
>> in my stable directory. I had to do this by hand afterwards. I also had
>> to finish executing the rest of the script by hand after the above error
>> popped up. I guess I should file a bug report, but I wanted to see if
>> anyone else had seen this behavior. I'm sure I could figure out the
>> problem myself, but I'm running short of time to spend on it.
>
> If the commit_new_release script fails at some point (e.g., if there are 
> problems with subversion), it simply quits and all remaining tasks are not 
> done, including resetting the Externals.  That's unfortunate, but I didn't 
> see a way to make it more stable in that sense.  If you have an idea, let me 
> know.
>
> Cheers
>
> Andreas
>
>> 
>> Cheers,
>> 
>> Ted
>> -- 
>> Dr. Ted Ralphs
>> Associate Professor
>> Industrial and Systems Engineering
>> Lehigh University
>> (610)758-4784
>> tkralphs at lehigh.edu
>> www.lehigh.edu/~tkr2
>> _______________________________________________
>> BuildTools mailing list
>> BuildTools at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/buildtools
>> 
> _______________________________________________
> BuildTools mailing list
> BuildTools at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/buildtools
>