On Fri, Sep 5, 2008 at 3:50 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> [originally misposted in the wrong thread]
>
> Wait, I think I've got it!
>
> The problem is that the "svn:special" property is set to "link" on both
> the old and new file, so it never appears as a prop diff -- nor should
> it, since there's no difference.
Really? I'd expect that for a 'R'eplaced file, property diffs should
be based against the empty file, not against the deleted file.
--dave
> But (I think) the code that handles the "svn:special" property only gets
> activated when the property is added or removed. (I guess it would also
> get activated if the property value changed, but in practice, it's
> always "link" right now, since the details appear in the file text.
> Thus our concern here is with the property being added or removed.)
>
> I haven't investigated this line of reasoning yet, but will later
> tonight if no one beats me to it.
>
> -Karl
>
> Karl Fogel <kfogel_at_red-bean.com> writes:
>> BUCHMULLER Norbert <norbi_at_nix.hu> writes:
>>> I found a bug in Subversion. Can someone pls test it on the latest
>>> version? (Or tell me if it's a known bug that I overlooked.)
>>>
>>> If a symlink is replaced by a different symlink (svn rm link; ln -s foo
>>> link; svn add link; svn ci), everything goes fine, up to the point when
>>> you try to merge this change to a branch, as on the merge the element
>>> becomes a plain file (instead of a symlink).
>>>
>>> Note that this bug is similar to issue 2064, but is not the same. (Issue
>>> 2064 is about the merge of a change creating a new symlink, this one is
>>> about the merge of a change that replaces a symlink with a different one.
>>> Just to be sure, I tested that it is not a regression of 2064.)
>>>
>>> Note2: I understand that replacing an element this way is silly (it
>>> creates a new element with the same name but separate version history).
>>>
>>> See the attachment (rm_symlink+add_symlink+merge.sh) for a recipe how to
>>> reproduce the bug.
>>
>> Thank you for the excellent reproduction script. I can also reproduce
>> the bug, using your script.
>>
>> When I traced in with GDB, I set breakpoints on svn_client_merge_peg3(),
>> and on each of the merge_callbacks in libsvn_client/merge.c:
>>
>> /* The main callback table for 'svn merge'. */
>> static const svn_wc_diff_callbacks3_t
>> merge_callbacks =
>> {
>> merge_file_changed,
>> merge_file_added,
>> merge_file_deleted,
>> merge_dir_added,
>> merge_dir_deleted,
>> merge_props_changed,
>> merge_dir_opened,
>> merge_dir_closed
>> };
>>
>> Here's what I found:
>>
>> Breakpoint 11, svn_client_merge_peg3
>> (source=0x9b0f5e0 "", ranges_to_merge=0x9b0db18,
>> peg_revision=0xbfa635d8, target_wcpath=0x806fff8 "",
>> depth=svn_depth_unknown, ignore_ancestry=0, force=0, record_only=0,
>> dry_run=0, merge_options=0x0, ctx=0x9b0e338, pool=0x9b0d990) at
>> subversion/libsvn_client/merge.c:6569
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 5, merge_file_deleted
>> (adm_access=0x9b0f710, state=0xbfa62d4c, mine=0x9bb2710 "link",
>> older=0x9bb2810 "/tmp/tmp", yours=0x9b75f68
>> ".svn/tmp/tempfile.tmp", mimetype1=0x0, mimetype2=0x0,
>> original_props=0x9bc1348, baton=0xbfa63428) at
>> subversion/libsvn_client/merge.c:1062
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 4, merge_file_added
>> (adm_access=0x9b0f710, content_state=0xbfa62d5c,
>> prop_state=0xbfa62d58, mine=0x9bc20e8 "link", older=0x9b75f68
>> ".svn/tmp/tempfile.tmp", yours=0x9bc2380 ".svn/tmp/tempfile.2.tmp",
>> rev1=0, rev2=3, mimetype1=0x0, mimetype2=0x0,
>> prop_changes=0x9bc20f0, original_props=0x9b75e18, baton=0xbfa63428)
>> at subversion/libsvn_client/merge.c:821
>> (gdb) c
>> Continuing.
>> --- Merging r3 into '.':
>> R link
>>
>> Hmmm, at this point, 'link' on disk is not a symlink. The "svn:special"
>> prop (needed to turn it into a symlink) was not delivered via
>> prop_changes and original_props (I stepped through earlier to make
>> sure). Then later we hit this:
>>
>> Breakpoint 10, merge_props_changed
>> (adm_access=0x9b0f710, state=0xbfa62ef4, path=0x9b8c6c8 "",
>> propchanges=0x9b8c6a8, original_props=0x9b927d0, baton=0xbfa63428)
>> at subversion/libsvn_client/merge.c:536
>>
>> ...However, when I step through, it just sets some svn:entry props. It
>> still didn't supply svn:special. After that, we don't hit any merge
>> callbacks (except for merge_dir_closed(), I think).
>>
>> I haven't traced the problem to its source yet, but I'm posting this in
>> hopes of saving you or someone else some time, if you decide to try
>> debugging it.
>>
>> -Karl
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
>> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-06 02:56:19 CEST