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
Received on 2008-09-06 00:08:04 CEST