> 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.
If there were an elevated form of 'C' for conflict, that would work.
Something that is still resolvable, but illustrates that some reading
will be needed by the merge guy/girl before resolving it. I'm
thinking a status code of 'F' (Greg, Fitz and Karl know my love of
crossing politeness lines in the pursuit of mischief - so they can
explain what it stands for if you can't guess).
As it happens, some of our tree-conflicts were items that ended with a
delete. The hacky patch we made, leaves that as 'C' but with file
(correctly) missing in the working copy. In that particular case, it
we marked as resolved, committed* then did a merge again to see if it
was offered for merge a second time - it was not - yay!
* we were working on a server side clone of our production repo - this
is work to be done for real today.
>
> 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.
I disagree.
Its perfectly possible for subversion to follow a different workflow
for merge :- http://subversion.tigris.org/issues/show_bug.cgi?id=3497
Bailing with a non-zero return code at the end of the merge is just as
communicative than bailing mid-way. It has the added benefit of
allowing folks to actually complete the merge, rather than start
revert (repeat 20 times).
>
> 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.
Tim Reaves (one of our project's tech leads) is re-doing Johnathon's
patch to effectively have the same behavior, and this likes that
command line flag idea.
- Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398956
Received on 2009-09-23 18:24:17 CEST