[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Fix issue #3001

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2007-10-31 14:13:49 CET

Senthil,
Instead of changing subversion/libsvn_repos/load.c's
'parse_property_block' to prefix mergeinfo sources with '--parent-dir',
please use 'set_node_property'.

With regards
Kamesh Jayachandran

Kamesh Jayachandran wrote:
> I think I found the cause.
>
> I think r27445 is just wrong in assuming revision_baton.
>
> 'subversion/libsvn_repos/load.c' has 'private node_baton' which is
> totally different from subversion/svndumpfilter/main.c's private
> 'node_baton_t' even though their names look alike.
>
> For svndumpfilter '--parent-dir' is of no use.
>
> Now we have to figure out how best to differentiate between
> 'svndumpfilter' and svnadmin's usage of this block of code.
>
> With regards
> Kamesh Jayachandran
>
>
>
> Kamesh Jayachandran wrote:
>> Just to give the more context based on our finding yesterday.
>> issue 2983 has introduced this via r27445.
>>
>> Simple recipe to prove this,
>> svnadmin create /tmp/repo
>> svn co file:///tmp/repo wc
>> cd wc
>> svn mkdir trunk
>> svn ps 'name' 'val' (This is very very important to trigger this issue).
>> svn ci -m 'log'
>> svnadmin dump /tmp/repo >/tmp/dmp
>>
>> svndumpfilter include non-existent </tmp/dmp (Would cause a segfault).
>>
>> svndumpfilter calls 'svn_repos_parse_dumpstream2' with 'struct with
>> filter functions' and a in-stream. When 'svn_repos_parse_dumpstream2'
>> reads from this instream it gets 'Node-path: trunk' header ahead of
>> 'Revision: 1'(dump looks perfectly fine in order 'Revision: 1' ahead
>> of Node-path !!) header and hence 'revision-baton' is NULL and hence
>> the segfault.
>>
>>
>> With regards
>> Kamesh Jayachandran
>> Senthil Kumaran S wrote:
>>> Kamesh Jayachandran wrote:
>>>> As we discussed yesterday, This may be the correct fix. But you
>>>> need to find why 'revision baton' is NULL before attempting to
>>>> fixing this.
>>>
>>> Kamesh, I am in the process of finding the exact reason for revision
>>> baton to be NULL here. Meanwhile, if anyone can let me know the
>>> reason, it will be great :)
>>>
>>> Thank You.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 31 14:14:29 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.