Kari Grano wrote:
> Hi devs,
>
> I finally got brave enough to try the 1.5.0 nightly on our production
> software. Some findings, and a showstopper:
>
> - I tried the "Merge" command for merging changes from a branch to
> trunk (the first option)
>
> - 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,10176-10177,10178-10180,10183-10184,10185-10186,10187-10188,10189-10191,10193-10195,10196-10197,10198-10199,10200-10201,10202-10206,10208-10211,10216-10217,10218-10219,10228-10230,10232-10235,10237-10239,10240-10241,10242-10245,10248-10249,10250-10253,10254-10255,10256-10257,10259-10260,10261-10264,10265-10266,10275-10276,10280-10281,10282-10284,10288-10289,10293-10295,10296-10297,10298-10301,10302-10306,10308-10315,10319-10321,10322-10323,10324-10325,10327-10330,10333-10335,10338-10340,10342-10343,10344-10348,10350-10356,10357-10364,10365-10367,10368-10369,10371-10380,10381-10382,10383-10385,10388-10390,10392-10393,10396-10401,10403-10404,10408-10411,10414-10416,10417-10421,10422-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.
> - Ok so far. Then I went on and started the merge
>
> - 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,10176-10177,10178-10180,10183-10184,10185-10186,10187-10188,10189-10191,10193-10195,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
our own list control, which I won't do, especially not before 1.5 comes
out :) )
> - 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.
> - The merge was interrupted from time to time by the new interactive
> conflicts dialog. I was able to resolve conflicts with it rather
> nicely for the first few times.
>
> - 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.
> - Major bug 3: The merge went thru until revision range 10414-10416,
> where it stopped with error "Malformed URL for repository". I
> attempted merging any of the "later" revisions individually, but they
> all resulted in the same error. Apparently SVN 1.5 thinks there is
> something wrong in the repository. Unfortunately I cannot publish
> the repo contents. However, I did run the exact same merge using
> TSVN 1.4.3 without any errors. The Apache error log contains the
> following entry:
>
> [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
> - 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.
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).
> - 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.
The problem with "ignore ancestry" is fixed in r13231.
> - 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
>
> This was really strange. The "merge without asking" option was not
> checked during the merge, and there had already been several
> conflicts according to the merge status window.
Strange indeed. I'll do some tests...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-06-12 19:38:00 CEST