[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.
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
Received on 2008-09-06 00:51:09 CEST