On Wed, Jul 1, 2009 at 9:49 AM, Paul Burba<ptburba_at_gmail.com> wrote:
> On Wed, Jul 1, 2009 at 7:41 AM, Julian Foad<julianfoad_at_btopenworld.com> wrote:
>> I (Julian Foad) wrote:
>>> On Mon, 2009-03-02 at 16:34 -0500, Paul Burba wrote:
>>> > I have been unable to replicate this problem, but with Brian's help
>>> > have determined that it doesn't exist in 1.6.0 Release Candidate 3
>>> > (and presumably trunk). The error still occurs with 1.5.7 Dev
>>> > however. I am still trying to figure out what needs to be backported
>>> > from trunk to 1.5.x to fix this [...]
>>>
>>> Hi Paul and others. I am looking at this problem for a client.
>>>
>>> Obviously upgrading to 1.6.x will be a recommended fix. In case
>>> upgrading is not a good solution for some other reason, I'd be
>>> interested to know if (a) you were ever able to reproduce this and (b)
>>> if there is any identified cause or fix.
>>
>> I am able to reproduce the problem with a 1.5.x client
>> (^/branches/1.5.x/@38201) by using the recipe at
>> <http://groups.google.com/group/google-code-hosting/browse_thread/thread/47ef0b9691e2af8e>.
>>
>> Some significant revisions of that repository are:
>>
>> ------------------------------------------------------------------------
>> r1 | jablko | 2007-10-03 19:55:01 +0100 (Wed, 03 Oct 2007) | 2 lines
>> Changed paths:
>> A /branches
>> A /tags
>> A /trunk
>>
>> Create default structure.
>>
>> ------------------------------------------------------------------------
>> r1426 | jablko | 2008-10-02 17:50:57 +0100 (Thu, 02 Oct 2008) | 3 lines
>> Changed paths:
>> A /qubit (from /trunk:1425)
>> D /trunk
>>
>> First step in vendor branches repository reorganization: Rename trunk to
>> make room for new parent trunk directory.
>> http://qubit-toolkit.org/wiki/index.php?title=Vendor_branches
>>
>> ------------------------------------------------------------------------
>> r1427 | jablko | 2008-10-02 18:32:35 +0100 (Thu, 02 Oct 2008) | 6 lines
>> Changed paths:
>> D /qubit
>> A /trunk
>> A /trunk/qubit (from /qubit:1426)
>>
>> M /trunk/qubit/lib/vendor
>> A /trunk/qubit/lib/vendor/symfony
>> A /trunk/qubit/lib/vendor/symfony/CHANGELOG
>> A /trunk/qubit/lib/vendor/[...]
>> A /trunk/qubit/lib/vendor/symfony/test/unit/yaml/sfYamlParserTest.php
>>
>> D /trunk/qubit/patches/component-class-name.patch
>> D /trunk/qubit/patches/[...]
>> D /trunk/qubit/patches/yaml-inline.patch
>>
>> A /trunk/symfony
>> A /trunk/symfony/vendor
>> A /trunk/symfony/vendor/CHANGELOG
>> A /trunk/symfony/vendor/[...]
>> A /trunk/symfony/vendor/test/unit/yaml/sfYamlParserTest.php
>>
>> Finish vendor branches repository reorganization:
>> Add new parent trunk directory and make qubit and symfony its children.
>> Initial symfony vendor drop from:
>> http://svn.symfony-project.com/branches/1.1
>> Remove symfony Subversion externals property and copy symfony vendor
>> branch to qubit.
>> Apply patches to qubit symfony branch and remove the obsolete patches.
>>
>> ------------------------------------------------------------------------
>> r2414 | jablko | 2009-04-25 06:03:59 +0100 (Sat, 25 Apr 2009) | 2 lines
>> Changed paths:
>> A /PHP_CodeSniffer (from /trunk/PHP_CodeSniffer:2413)
>> A /drupal (from /trunk/drupal:2413)
>> A /qubit (from /trunk/qubit:2413)
>> A /sfThumbnailPlugin (from /trunk/sfThumbnailPlugin:2413)
>> A /symfony (from /trunk/symfony:2413)
>> D /trunk
>> A /yui (from /trunk/yui:2413)
>>
>> First step in repository reorganization, move children of trunk to root
>> and delete trunk
>>
>> ------------------------------------------------------------------------
>> r2415 | jablko | 2009-04-25 06:33:27 +0100 (Sat, 25 Apr 2009) | 2 lines
>> Changed paths:
>> D /qubit
>> A /trunk (from /qubit:2414)
>>
>> Finish repository reorganization
>>
>> ------------------------------------------------------------------------
>> r2550 | jablko | 2009-05-13 17:42:21 +0100 (Wed, 13 May 2009) | 2 lines
>> Changed paths:
>> A /branches/dcb (from /trunk:2549)
>>
>> Create Digital Collection Builder branch
>>
>> ------------------------------------------------------------------------
>>
>>
>> I confirm the following:
>> [[[
>> $ svn co -r 2575 http://qubit-toolkit.googlecode.com/svn/branches/dcb
>> $ cd dcb
>> $ svn merge http://qubit-toolkit.googlecode.com/svn/trunk
>> svn: Unable to parse reversed revision range '1427-1426'
>> ]]]
>>
>> I have written the attached test script to try to mimic this series of
>> events but I have missed something because the test script doesn't fail.
>>
>> - Julian
>
> Hi Julian,
>
> Wow, this brings back some bad memories :-)
>
> Despite an immense amount of off-list cooperation from Brian I was
> never able to replicate this on 1.5, so was never able to pinpoint the
> fix(es) to be backported. With the googlecode example though I should
> now be able to figure it out now. I'll take a look today.
>
> Paul
Hey Julian,
Well that was awful, but at least I finally have something to debug!
The problem ultimately looks attributable to
merge.c:prepare_subtree_ranges(), which is creating rangelists with
svn_merge_range_t elements that have svn_merge_range_t.start ==
svn_merge_range_t.end, which is a no-no:
/**
* Mergeinfo representing a merge of a range of revisions.
*
* @since New in 1.5
*/
typedef struct svn_merge_range_t
{
/* If the 'start' field is less than the 'end' field then 'start' is
* exclusive and 'end' inclusive of the range described. If 'start'
* is greater than 'end' then the opposite is true. If 'start'
* equals 'end' the meaning of the range is not defined.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*/
svn_revnum_t start;
svn_revnum_t end;
/* Whether this merge range should be inherited by treewise
descendants of the path to which the range applies. */
svn_boolean_t inheritable;
} svn_merge_range_t;
As mentioned earlier in this thread, this problem does not exist in
1.6 (again, all that is needed is the 1.6 client). Turns out this is
due to a substantial reworking of this code I did to address issue
#3067 (see r34016 and the issue-3067-deleted-subtrees branch).
r34016 introduced a new API svn_ra_get_deleted_rev, though it has a
Subversion private work-around svn_ra__get_deleted_rev_from_log() for
dealing with pre 1.6 servers. I suppose it's possible we could
backport that workaround and the rest of r34016 to 1.5 except for the
new API...but it is a not insubstantial amount of work and I have
*zero* confidence that it would get the review and votes needed for
backport. Getting review of far simpler merge tracking changes has
proven a real problem and r34016 is far, far more complicated than any
merge tracking fixes that have been backported.
Also, searching users, it doesn't seem that this is a common problem.
Given all of the above and barring a really compelling reason, I feel
that the solution here is "upgrade to a 1.6 client", though I am of
course open to arguments to the contrary.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2367189
Received on 2009-07-01 22:56:24 CEST