Kari Grano wrote:
>> That's because the list control can't show more than these characters on
>> one line. There's nothing we can do about that (apart from implementing
>
> Fair enough. I noticed that select all + paste actually found the "hidden"
> part.
That's because TSVN keeps the information itself too, not just in the
list control.
>>> - Finding: The "new" merge appears to be very slow. I would estimate
>>> it is 5-10 times slower than with 1.4.x client. Is there anything one
>>> can do about it? Or is it because our server is still 1.4.x?
>> Yes, that has been reported a lot on the svn mailing list. You get the
>> speed back if you upgrade your server.
>
> I was kinda hoping for a secret setting to run the merge in mergeinfo-less
> mode when operating with older servers :-). The speed hit is so bad that I
> guess server upgrade is a must.
I'd say so, yes.
>>> - Minor bug 2: Sometimes the interactive conflicts dialog popped up
>>> behind all other windows, making it hard to realize there is a
>>> conflict. It would be nice if the conflict resolution window would be
>>> forced topmost.
>> I know about that, but I haven't found out how to force the dialog on
>> top: I already set the parent window of that dialog, so it *should*
>> appear on top of the progress dialog.
>> All I know is that is has something to do with the different threads the
>> dialogs are created.
>
> Wild guess: have you tried to call SetForegroundWindow() when displaying the
> conflict resolution dialog?
That's won't help.
I've changed the code now so that the dialog is not created on the
worker thread anymore. It should work correctly now.
>>> - Major bug 3: The merge went thru until revision range 10414-10416,
>>> where it stopped with error "Malformed URL for repository". [...]
>>> TSVN 1.4.3 without any errors. The Apache error log contains
>>> [Thu Jun 12 18:34:23 2008] [error] [client x.x.x.x] The requested
>>> report is unknown. [501, #200007]
>
>> I think that should be fixed by now:
>> http://svn.haxx.se/dev/archive-2008-04/0077.shtml
>
> I'll try the username-on-url trick tomorrow. However, I did not see the case
> get resolved in the mail thread?
Not there, but I *think* there was another thread where it lead to a fix.
Just to make sure: you should report it on the Subversion mailing list
too so they can find the reason for this and investigate some more.
>>> - Major bug 4: I reverted the working copy and retried the merge, now
>>> checking the "merge without asking" checkbox. In this case the merge
>>> was interrupted by TSVN crashing in the middle (around revision 10250
>>> I recall). I've attached the produced crash dump.
>> Are you using serf instead of neon? (Check your subversion servers
>> config file).
>> There have been some fixes for segfaults during merge.
>
> I would assume neon, since we never change the install-time defaults. I'll
> check tomorrow.
>
>> It would help a lot if you could install the 32-bit version of TSVN and
>> send the crashdump file for that (also use the RC3, not a nightly build
>> where I don't keep the debug symbols).
>
> Ok, I'll try that.
>
>>> - Minor bug 5: After reverting, I retried the merge in test mode with
>>> varying settings. I noticed that the "merge without asking" checkbox
>>> is present in test mode. IMO it does not make sense to resolve
>>> conflicts during dry run. Also, the "ignore ancestry" setting was
>>> not displayed correctly (was always "use ancestry") in test mode
>>> output.
>> resolving conflicts in test mode is useful to check what conflicts you
>> can expect when you do the merge. Some people like to do that.
>
> I see. Hopefully the resolutions are then temporary too?
Yes.
>> The problem with "ignore ancestry" is fixed in r13231.
>
> Thanks.
>
>>> - Major bug 6: During test mode, TSVN suddenly opened the "resolve
>>> conflicts" dialog. *At the same time*, it re-opened the final merge
>>> wizard page on top of it. Canceling both dialogs resulted in the
>>> following messages in the merge output:
>>> Error: User cancelled Error: Error reading spooled REPORT request
>>> response
>
>> Strange indeed. I'll do some tests...
>
> Some more info: if you closed the last page of the merge wizard, clicking
> anywhere (that is, non-button area) on the conflict resolution window
> reopened the last page of the merge wizard.
That shouldn't happen anymore now since I don't show the dialog on the
worker thread anymore.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-06-12 21:00:45 CEST