Am Freitag, 7. September 2018 22:23:44 UTC+2 schrieb Stefan: > > Seems the problem is inside the svn library. > You should report it on the svn mailing list: > http://subversion.apache.org/mailing-lists.html >
My conversation with the SVN mailing list: On Sun, Sep 30, 2018 at 04:06:08PM +0000, Knauß, Tobias wrote: > Hello, > > First, as suggested on the mailing list page, I should mention that I am not subscribed to the mailing list, so please add me in CC on the responses. > I also don't know if the mailing list accepts HTML, so I chose plain-text, but this does not allow adding screenshots, so for convenience you may simply look at the conversation at the TortoiseSVN google group, where I first posted about the possible bug in your svn library: > https://groups.google.com/forum/#!topic/tortoisesvn/qUoGtI8hxJ8 > > I have added the first and last message here: > > ------------------------------------------------------------------- > Message #01, Tobias Knauss, 2018-09-07: > > I created a branch at revision 2000 of the trunk. > I renamed some files in the trunk at revision 2141. > I edited these files in the branch at revision 2194. > Now I want to merge the changes from the branch back to the trunk, but it causes a tree conflict because files have been renamed there. This is okay. > > Not okay is, that a window pops up and tells me "fetching tree conflict information" and searches back until revision 1359 and hangs there forever. In r1359 we had many edits (files and folders renamed, files deleted) because we converted our code from C++/CLI (.cpp, .h) to C# (.cs). Somehow this fetching dialog doesn't like that, even though the conflicting files were not part of the commit for r1359. > <screenshot of TortoiseSVN dialog window "Edit Tree Conflicts", saying > "Fetching tree conflict information..." and stuck at "checking r1359"> > > Why does it hang? Why does it search back so far? It's not needed. Hi Tobias, Thank you for your report. There are two known bugs which cause this type of problem. A patch for the first bug has been released in Subversion 1.10.2. Does your version of TortoiseSVN include Subversion 1.10.2? The second bug has no released fix yet, so this is the likely culprit. This fix is in the pipeline for upcoming SVN 1.10.3 and also for upcoming SVN 1.11.0. If TortoiseSVN could backport this fix to their pre-release build version and you could test it, that would be appreciated. https://svn.apache.org/r1839662 ------------------------------------------------------------------------ r1839662 | stsp | 2018-08-30 13:39:40 +0200 (Thu, 30 Aug 2018) | 17 lines Don't scan for moves for 'local missing' conflicts unless a YCA is known. Prevent the resolver from embarking on an endless search in case of a 'incoming edit vs. local missing' conflict where no YCA can be found which would cap our search through history. Reported by: Dag-Erling Smørgrav <...> https://svn.haxx.se/users/archive-2018-08/0038.shtml * subversion/libsvn_client/conflicts.c (find_deleted_rev): Account for a NULL moves-table. (find_operative_moves, find_revision_for_suspected_deletion): Make search for moves optional. The caller can now pass a NULL moves array to indicate that moves should not be searched for. (conflict_tree_get_details_local_missing): Only ask for move information if a YCA was found. ------------------------------------------------------------------------ Thanks, Stefan -- You received this message because you are subscribed to the Google Groups "TortoiseSVN" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/005bc4ec-0974-4602-b59c-7c70ba95cc4a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
