[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.6.0-rc1 tarballs up for signing/testing

From: Paul Burba <ptburba_at_gmail.com>
Date: Wed, 18 Feb 2009 09:48:00 -0500

On Mon, Feb 16, 2009 at 4:14 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Good afternoon,
>
> I'm pleased to announce that Subversion 1.6.0-rc1 is up for testing
> and signing. The magic revision is r35896.
>
> http://orac.ece.utexas.edu/pub/svn/1.6.0-rc1/
>
> As usual, signatures from full committers back to me, and enthusiastic
> tester feedback is welcome. At this point, this candidate is not yet
> blessed for wide release, so please don't make it available to people
> not interested in test-driving the new release. Please especially
> test the serf RA layer, and consider including it in your typical
> testing routine.
>
> Distro package maintainers, please to NOT include any pre-release
> builds, even blessed, into operating system distros. The reasons for
> not doing so were very eloquently outlined by Karl in a mail, which is
> summarized at the above address.
>
> The quick version is: we don't guarantee compatibility between the pre-
> releases and the final release, so if people install the release
> candidate, all their repositories and working copies might break
> unrepairably when they upgrade to 1.6.0 proper. We don't want that
> kind of bad publicity, and neither do you.
>
> -Hyrum

TESTED:
-------
[ fsfs | bdb ] x [ file | svn | http (neon) ]
JavaHL Bindings

SUCCESSFULLY BUILT BUT NOT TESTED:
----------------------------------
Python Bindings
Perl Bindings

SUMMARY:
--------
+1 to release.

RESULTS:
--------
JavaHL: Pass

[ fsfs | bdb ] x [ file | svn | http (neon) ]: All pass except as noted below:

[ fsfs | bdb ] x [ file | svn | http (neon) ]

basic_tests.py 12: 'basic revert command' failed due a problem with
that test on Windows with Python 2.5+. I fixed this on trunk in
r35930. With that fix applied to 1.6.x this test passed all
variations. As this was simply a problem with the test suite it does
not prevent release.

[ bdb ] x [ http (neon) ]

FAIL: tree_conflict_tests.py 10: merge file: del/rpl/mv onto not-same
FAIL: tree_conflict_tests.py 11: merge file: del/rpl/mv onto not-file
FAIL: tree_conflict_tests.py 12: merge file: add onto not-none
FAIL: tree_conflict_tests.py 16: merge dir: add onto not-none

[ bdb ] x [ svn ]

FAIL: tree_conflict_tests.py 9: merge file: modify onto not-file
FAIL: tree_conflict_tests.py 10: merge file: del/rpl/mv onto not-same
FAIL: tree_conflict_tests.py 11: merge file: del/rpl/mv onto not-file
FAIL: tree_conflict_tests.py 12: merge file: add onto not-none
FAIL: tree_conflict_tests.py 13: merge dir: modify onto not-dir
FAIL: tree_conflict_tests.py 16: merge dir: add onto not-none

All of the above tree_conflict_tests.py failures were due to the
inability of the tests to delete the repository when building multiple
sandboxes. I fixed this on trunk in r35943. After merging that
change to 1.6.x all of these tests passed. Again, this was a problem
with the test suite and is not sufficient to stop release.

[ bdb ] x [ file ]

FAIL: fs-test.exe 18: merging commit

The XFail on this test was incorrectly removed in r35347. It was set
back to XFail on trunk in r35945 (see also r35948). In the course of
investigating these failures I found a bug in the fsfs implementation
of svn_fs_commit_txn(): If the commit failed, the *NEW_REV argument
was not set to SVN_INVALID_REVNUM as the API promises:

 * @note Success or failure of the commit of @a txn is determined by
 * examining the value of @a *new_rev upon this function's return. If
 * the value is a valid revision number, the commit was successful,
 * even though a non-_at_c NULL function return value may indicate that
 * something else went wrong.
 */
svn_error_t *
svn_fs_commit_txn(const char **conflict_p,
                  svn_revnum_t *new_rev,
                  svn_fs_txn_t *txn,
                  apr_pool_t *pool);

This was fixed in r35950, but given that this bug has existed since
the dawn of FSFS in 1.1.0, it seems all callers are relying on the
returned error and/or the value of **CONFLICT_P rather than the value
of *NEW_REV. So nominating this for backport to 1.6.1 seems
sufficient.

VERIFIED:
-------
http://orac.ece.utexas.edu/pub/svn/1.6.0-rc1/stingray/subversion-1.6.0-rc1.zip:

MD5:
SHA1: f05c3ae8d3223cccc6991dbd670d4b68def8febe

Excepting subversion/include/svn_version.h the contents of
http://orac.ece.utexas.edu/pub/svn/1.6.0-rc1/stingray/subversion-1.6.0-rc1.zip
match http://svn.collab.net/repos/svn/branches/1.6.x@35896.

PLATFORM:
---------
Microsoft Windows XP Professional Service Pack 3 (Build 2600)
AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ 2211.2 Mhz 2 GB RAM
Microsoft Visual Studio 2008 Professional Version 9.0.21022.8 RTM
Microsoft .NET Framework Version 3.5

DEPENDENCIES:
-------------
APR: 1.3.3
APR-UTIL: 1.3.4
Neon: 0.28.2
zlib: 1.2.3
OpenSSL: 0.9.8h
Apache: 2.2.10
BDB: 4.7.25
sqlite: 3.6.10
Python: ActivePython 2.6.1.1
java: 1.6.0_07
swig: 1.3.36

SIGNATURE:
-----------
user: "Paul T. Burba <ptburba_at_gmail.com>"
1024-bit DSA key, ID 53FCDC55, created 2006-06-21

http://orac.ece.utexas.edu/pub/svn/1.6.0-rc1/stingray/subversion-1.6.0-rc1.zip:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQBJmtXc2RaJMFP83FURAsZ7AJ420xEXCtMfXeqNLyF74bxc7rLiqACdHIWE
emJePmbTb+7LZF1Euko2Czw=
=hCN4
-----END PGP SIGNATURE-----

Paul

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1186391
Received on 2009-02-18 15:48:28 CET

This is an archived mail posted to the Subversion Dev mailing list.