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

Re: back-end fsfs DB corruption? - attempt to merge uncovering it

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 15 Sep 2009 20:37:00 +0100

On Tue, Sep 15, 2009 at 01:59:16PM -0500, Paul Hammant wrote:
> Stefan,
>
> The setup for the merge attempt involves reverting all, force deleting
> files non under SCM, svn up, svn st ...
>
> ... the running the merge with "--accept theirs-full"
>
> This to me is as good as a clean checkout. If you think it makes a
> difference, we can do that too.

If "svn status" is clean, that's fine.

> Our workaround will be the other advice that we've seen.
>
> merge 1 - everything up to the breaking CL; then commit
> merge 2 - merge the breaking CL and commit it.
> merge 3 - everything since the breaking CL & commit.
>
> We'll kiss goodbye to the bug then. After that, we'll be true trunk-
> based development, rather than multiple feature branches, so are not
> likely to see it return.

OK, one last question if I may:

Are you sure that the svn binary you've built is using the correct
libsvn_* libraries? If it happens to load the old ones, which can
happen on Linux where shared lib dependencies are resolved at runtime,
depending on your configuration, then it could be calling into a wrong
shared library which does not have the fix applied.

Stefan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395217

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-15 21:38:06 CEST

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

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