On Mon, Dec 9, 2013 at 11:03 PM, Ivan Zhakov <i...@visualsvn.com> wrote:
> On 5 December 2013 00:15, Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> > wrote: > > Hi all, > > > > I've spent the last two days getting our test suite to pass > > with our backward compat option. That mostly worked for > > 1.5 through 1.9 (with one exception). > > > > The problem is however, that we not only create repositories > > in the respective older format version but also expect the > > server to behave as the respective older release does. This > > causes two types of problems: > > > > * Tests depending on server capabilities see unexpected > > behavior, e.g. srv-min-ver=6 against a 1.9 svnserve: > > > > FAIL: prop_tests.py 34: test revprop atomicity guarantees of libsvn_ra > > (because the server has *_ATOMIC_REVPROP capability) > > > > Pre-1.5 tests show even more discrepancies like different > > wording in error messages etc. So, this class of tests cannot > > run against a new server then advertised. > > > > * Many more tests fail when the test are actually run against > > a svnserve of the specified minor version because the > > respective feature, e.g. svnrdump / svnsync, are not > > available at all. > > > > Thus, we can't use that combination, to verify that old data > > (still) gets processed correctly. > > > > Apart for skipping many tests, there is no way to make the > > current test suite pass for pre-1.7 server and data. > > > > Suggestion: Redefine / introduce new options: > > > > --server-minor-version (actual server version) > > --repository-minor-version (highest format supported by SVN 1.minor) > > --created-minor-version (create repositories with this older format > > and then upgrade to --repository-minor-version). > > > > Given that most feature presence checks test for mergeinfo, > > it should not be too hard to move existing tests over to the > > new scheme. > > > I'm not familiar with how test suite implemented, but your suggestions > sounds good for me as test suite 'user'. For me > --server-minor-version is for RA compatibility, so we need something > different for FS version to test. > Technically, it's not so much about the RA layer / lib but also about the actual older servers behaving differently (e.g. producing slightly different error messages; reporting different caps etc.). > [Bikeshed mode] May be it's better to use '--repository-version' and > '--upgrade-repository-from' to use full version number? > Sounds good. January project. -- Stefan^2.