Hi Stefan,
>> - I selected the range to be merged with the Show log button as
>> 10142-10428. This appeared in the wizard as
>>
10141-10142,10145-10146,10149-10150,10152-10156,10158-10160,10163-10175,1017
6-10177,10178-10180,10183-10184,10185-10186,10187-10188,10189-10191,10193-10
195,10196-10197,10198-10199,10200-10201,10202-10206,10208-10211,10216-10217,
10218-10219,10228-10230,10232-10235,10237-10239,10240-10241,10242-10245,1024
8-10249,10250-10253,10254-10255,10256-10257,10259-10260,10261-10264,10265-10
266,10275-10276,10280-10281,10282-10284,10288-10289,10293-10295,10296-10297,
10298-10301,10302-10306,10308-10315,10319-10321,10322-10323,10324-10325,1032
7-10330,10333-10335,10338-10340,10342-10343,10344-10348,10350-10356,10357-10
364,10365-10367,10368-10369,10371-10380,10381-10382,10383-10385,10388-10390,
10392-10393,10396-10401,10403-10404,10408-10411,10414-10416,10417-10421,1042
2-10428
> hmm - while that seems to be correct, I think we could do better here by
> just adding the full range. Subversion would skip the missing revisions
> itself.
Agreed. The merge status window is displaying the subranges anyway.
>> - Minor bug 1: The merge status window cut the revision range message
>> (shown on the first line) as Command: Merging revisions
>>
10141-10142,10145-10146,10149-10150,10152-10156,10158-10160,10163-10175,1017
6-10177,10178-10180,10183-10184,10185-10186,10187-10188,10189-10191,10193-10
195,10196-10197,10198-10199,10200-10201,10202-10206,10208-10211,10216-10217,
10218-10219
>> I would have expected the same range.
> 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.
>> - 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.
>> - 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?
>> - 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?
>> - 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?
> 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.
BR,
Kari.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-06-12 20:33:11 CEST