[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: Paul Hammant <paul_at_hammant.org>
Date: Tue, 15 Sep 2009 13:59:16 -0500


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.

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.

- Paul

On Sep 15, 2009, at 1:40 PM, Stefan Sperling wrote:

> On Tue, Sep 15, 2009 at 01:29:34PM -0500, Paul Hammant wrote:
>> Stefan,
>> Building 1.6.x-r38000 (requires libtool install, sqllite stuff, etc)
>> makes a Svn. Testing that one (again hard coded path), yields the
>> same halt point:
> Are you, by any chance, merging into a working copy which has the
> conflict already recorded from a prior merge?
> If so, does the merge work if you get a clean working copy and use
> that to do the merge?
> Stefan


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-15 21:00: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.