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

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.

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
>

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

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