Sigh, massive update to the repository, as Oyvind warned. I will do a
clean build and run some subset of tests to make sure we're still OK.
David
Rick Hillegas wrote:
Hi David,
I think that this is all speculation about what to do in the future as
we migrate existing tests into JUnit. No-one has proposed blocking this
patch. Please go ahead with the commit.
Thanks,
-Rick
David W. Van Couvering wrote:
I am *this* close to checking in Rick's patch. Should I hold off, or
can we do this as a separate patch?
David
Rick Hillegas wrote:
What I meant by "fork" is that we could introduce a new subdirectory
under org/apache/derbyTesting as Myrna suggested. Then, as tests were
converted to JUnit, we could move them from their old location to a
new location under the JUnitTests subdirectory. Moving would involve
svn-moving the test, which means that the old version would disappear
from the code tree. There would be only one version of the test in
the code tree. I agree that maintaining two independent copies would
be a bad idea.
-Rick
Daniel John Debrunner wrote:
John Embretsen wrote:
Rick Hillegas wrote:
Myrna van Lunteren (JIRA) wrote:
[snip]
Finally I also wondered if maybe these tests ought to be not under
org/apache/derbyTesting/functionTests/tests/compatibility, but under
org/apache/derbyTesting/JUnitTests/compatibility...
I don't have strong religion about these points either. Concerning
the
last issue: I agree that a JUnitTests fork in the tree might help us
track which of our existing tests we've migrated under JUnit.
I agree, I think we could avoid a lot of potential confusion regarding
Derby testing in the future by having (from the start) an easy way to
see which tests are written for JUnit and which are not, especially as
more JUnit-based tests are added. Forking the derbyTesting source tree
might be a good way to do this - at least I cannot come up with any
better ideas at the moment.
Do you mean forking, or just a separate directory structure within
derbyTesting?
Forking means a copy of the tree developed independently, not sure why
we would want to go down that path.
Dan.
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
