On Wed, Sep 23, 2009 at 04:03:49PM +0100, Stefan Sperling wrote:
> On Wed, Sep 23, 2009 at 10:53:18AM -0400, Mark Phippard wrote:
> > Thanks Julian, I relayed the same advice.
> >
> > The patch has been posted to users@. See:
> >
> > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2398899
> >
> > Hopefully some of the tree conflicts gurus can look at it from an
> > approach standpoint and see if there is maybe a different way we can
> > handle these error situations.
>
> Oh, a patch?
> I will take look. Totally missed that thread...
That patch is not meant to be a formal submission.
And it would fail for various reasons if it was.
It shows how Paul and his team are trying to get more information
out of the system, but it is not a fix. Except that it ignores
the fatal error during the merge so the merge can continue.
I totally see the point of letting the merge continue.
The item in question could just be skipped by the merge.
But I'm not sure how we could transform the error into a warning.
It would have to go back up all the way to the client, then be
caught there, be ignored, and the client would need to resume
the merge. This isn't possible with the current API.
So if we don't throw that error, we never notice when this problem
surfaces. I'd rather have to fix any bugs causing us to hit this
error than not be getting any information at all about these bugs.
A better and more general approach might be an --skip-tree-conflicts
flag for update and merge, causing svn to skip any tree conflict victims
instead of flagging tree conflicts in the working copy.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398943
Received on 2009-09-23 17:17:54 CEST