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

Re: svn commit: r10091 - in trunk/subversion: include libsvn_repos svnadmin

From: <kfogel_at_collab.net>
Date: 2004-06-29 05:28:12 CEST

Ben Collins-Sussman <sussman@collab.net> writes:
> > Make svnadmin load less verbose by default and add a --verbose flag.
>
> Did we forget to run 'make check'? This breaks all the
> svnadmin_tests.py tests.

In fact it breaks *all* the .py tests, because of this code in
subversion/tests/clients/cmdline/svntest/main.py:copy_repos():

  load_re = re.compile(r'^------- Committed revision (\d+) >>>$')
  expect_revision = 1
  for load_line in load_lines:
    match = load_re.match(load_line)
    if match:
      if match.group(1) != str(expect_revision):
        print 'ERROR: load failed:', load_line,
        raise SVNRepositoryCopyFailure
      expect_revision += 1
  if expect_revision != head_revision + 1:
    print 'ERROR: load failed; did not see revision', head_revision
    raise SVNRepositoryCopyFailure

For now, I'll fix it by adding '--verbose' to the invocation in the
test framework, so we don't lose any more developer time on this.

However, in the long term, I feel it's wrong that we changed the
default output format of 'svnadmin load' in a 1.x release. The output
formats are part of the API. If anyone is tempted to argue with that,
I will simply point to the current situation as proof :-).

I don't think we need to revert r10091. We just need to tweak it so
that the default is verbosity; -q produces quiet operation; we file a
2.0 issue to change the default; and of course we can revert the
band-aid change I'm about to commit to the test suite.

Objections, alternatives?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 29 06:54:46 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.