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

Re: Status of TODO-1.6

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 07 Jan 2009 15:56:34 +0000

On Tue, 2009-01-06 at 19:07 +0000, Julian Foad wrote:
> On Thu, 2008-12-25 at 14:28 +0200, Daniel Shahaf wrote:
> > Hyrum K. Wright wrote on Wed, 24 Dec 2008 at 11:30 -0600:
> > > The following items are listed as blocking the branch of 1.6.x:
> > >
> >
> > One item I don't see listed explicitly is making commit_out_of_date_deletions()
> > pass over all RA layers again. It was marked XFail over ra_svn in r32971,
> > but isn't XFail in 1.5.x. (Maybe it should be added to issue #3209?)
>
> So is that a regression or a bug-fixing change of behaviour?

Answering myself...

The change in behaviour was due to r32901 which merged the
"double-deletes" branch to trunk. RA-svn fails to provide some part of
the new required protection against double-deletes.

The following change marked the test XFail over RA-svn:

------------------------------------------------------------------------
r34104 | kfogel | 2008-11-07 21:42:18 +0000 (Fri, 07 Nov 2008) | 9 lines

* subversion/tests/cmdline/commit_tests.py
  (test_list): Expect commit_out_of_date_deletions to fail over ra_svn.
    I'm not sure why it wasn't marked this way originally. See r34101
    and r34073 for more context; I think there was just a multi-way
    confusion here and that it is now un-confused.
------------------------------------------------------------------------

I think that, although there is a bug here, it isn't one that we would
call a regression or one that needs to be fixed before releasing v1.6.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1010078
Received on 2009-01-07 16:57:19 CET

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.