db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: [jira] Commented: (DERBY-1547) Add svn version number to DatabaseMetaData getDatabaseProductVersion and getDriverVersion() to improve supportability
Date Tue, 12 Sep 2006 07:35:40 GMT
On 9/11/06, V.Narayanan (JIRA) <derby-dev@db.apache.org> wrote:
>
> > getDatabaseProductVersion(): 10.3.0.0 alpha-(1)
> > getDriverVersion(): 10.3.0.0 alpha-(1)
> Test Failed.
>
> Can you please answer the following questions for me
>
> 1) Is this behaviour observed by you when running only with the classes directory or
when running with the jars also?

The setting of 1 for the build number indicates that the tests were
run against the classes directory in Kathey and Deepa's case.

When a basic (non-jar) build is made into the classes directory, the
build number is set to 1 to avoid running svnversion. svnversion scans
the entire local checkout for differences. Because svnversion can take
some time (over a minute if you have a slow machine and hard drive) to
determine the version of the local source tree and whether or not it
has been modified from what has been checked out, the default behavior
is to set the version to 1 and not use svnversion.

When the jars are built, the build number is set to the svn revision
as reported by svnversion, since building the jars is an extra step
that may not be necessary to test a local change and the extra time
will probably not be missed.

While it may be desirable to set the svnversion to the proper value
for the classes directory, I also think keeping the speed of the
default Ant target down to a minimum is desirable as well. So, if this
problem can be taken care of by a little extra grammar in a regular
expression for this test, I think that is probably the better route to
take for now.

andrew

Mime
View raw message