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

Re: svn commit: r1186144 - in /subversion/branches/1.7.x: ./ STATUS subversion/libsvn_fs_fs/fs_fs.c

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 19 Oct 2011 15:30:45 +0200

Stefan Sperling wrote on Wed, Oct 19, 2011 at 15:14:46 +0200:
> On Wed, Oct 19, 2011 at 03:07:52PM +0200, Daniel Shahaf wrote:
> > People who are bitten by this will not be able to commit anything with
> > this revision applied.
> Why? I thought this was some transient error, and that we prevent a bad
> revision from enterting the repository.
> > Should we add a way to turn off the new validation?
> If you're saying that this can prevent people from committing new
> revisions, because a wrong pred count in a transaction is a permanent,
> rather than transient error condition, I think we should pull this
> revision from 1.7.x.
> But why do you think that every transaction will have a wrong pred
> count once one transaction had a wrong pred count?

The revision works as intended for new repositories. But for
repositories where the predecessor count on "/" is already wrong, the
error doesn't fix itself...

If /@50's predecessor is /@20, then /@50's pred-count is 21; but /@51's
pred-count would be 22, not 51.

I'm working on a different fix that doesn't have this problem: checking
if 50 - 21 == 51 - 22, and erroring out if that's not the case.
Received on 2011-10-19 15:31:31 CEST

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.