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

Re: We're still going on 'tree conflict' issue

From: Paul Hammant <paul_at_hammant.org>
Date: Fri, 18 Sep 2009 10:10:22 -0500

On Sep 18, 2009, at 9:23 AM, Stein Somers wrote:

>> The fix is present on the not-yet-released 1.6.x-r38000 branch only.
> My findings completely confirm that. 1.6.x straight up still bails
> out,
> 1.6.x-r38000 completes the merge in the same verbose way as the /trunk
> version does.

For us, not so, though it is better than it was. For 1.6.x it breaks
about 2 mins into a merge. For 1.6.x-r38000 is goes past that item
and breaks 5 minutes later.

To speed things up, we're doing --accept theirs-full ( this allows us
to race to the break point ).

It is curious though, that when it breaks with 1.6.x-r38000 performing
the merge, it is less verbose that recent changes to 1.6.x.
Specifically, 1.6.x-r38000 is missing one or two essential change
lists around the extra file name...

    svn: Attempt to add tree conflict that already exists

versus ....

    svn: Attempt to add tree conflict that already exists at '%s'

Can someone merge that change from 1.6.x to 1.6.x-r38000 please ?

> The actual conflict that wrecks the merge for us is a "file replace"
> being
> merged in. But as explained in another thread recently, a "replace"
> really is
> a facade for a "delete" followed by an "add". Thus I guess that is
> why there
> are two tree conflicts on the same item in a single merge.

Will investigate and report back. It could be that this is us too.

> The wretched thing about this particular "file replace" is that it
> replaces
> the file by a copy of a copy of a previous revision of itself. No
> content
> change whatsoever. Somehow this silly change came about and got
> committed.


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