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

Re: bug candidate: replacing symlink with other symlink turns to plain file on merge

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Fri, 05 Sep 2008 18:07:55 -0400

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 =

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
   (gdb) c
   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
   (gdb) c
   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
   --- 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.


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

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.