On Tue, May 12, 2009 at 12:35 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Tue, May 12, 2009 at 12:31 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>> On Mon, May 11, 2009 at 6:20 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>>> On Mon, May 11, 2009 at 5:01 PM, Paul Burba <ptburba_at_gmail.com> wrote:
>>>
>>>> Hi John - Do you know how the mergeinfo in r40998 was created? Was it
>>>> the result of a merge or a propset/propedit or something else
>>>> entirely? Also, can you hazard a guess as to what version of
>>>> Subversion (or some other client tool) was used to make it?
>>>>
>>>> If possible I'd like to figure out how the <CR> got in your repository
>>>> in the first place before making any fixes to dump/load.
>>>
>>> I am not sure why we are thinking this is anything special (related to
>>> mergeinfo). We have had many reports of people running into this
>>> problem for all sorts of properties.
>>
>> Mark,
>>
>> I hadn't realized that, I see the various threads and issue #3404
>> related to svnsync. But dump/load with 1.6.2 works fine if there are
>> "\r\n" in, say, an svn:log property...
>
> Did you try it with svn:externals or any of the versioned properties?
Just did now, with svn:externals and the load works fine* with trunk
and 1.6.2. The reason svn:mergeinfo is a problem during a load is
that it is subject to special handling in the svn_repos_parse_fns2_t
set_node_property function (Senthil's change in r28978).
Paul
* Unlike mergeinfo with '\r', other versioned and unversioned props
are loaded intact, that is to say the '\r\n' are still present in the
loaded repos. My patch "fixes" the loaded mergeinfo props so there
are no '\r'. I could make loaded mergeinfo be treated the same way,
but I see no point in doing this!
> I might have been combining svnsync problems with dump/load but I
> thought we have seen it with both.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2218191
Received on 2009-05-12 19:50:06 CEST