You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by BUCHMULLER Norbert <no...@nix.hu> on 2008/09/05 09:15:01 UTC
bug candidate: replacing symlink with other symlink turns to plain
file on merge
Hi,
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.
Subversion version: 1.5.1 (1.5.1dfsg1-1 from Debian lenny)
O/S: Linux 2.6.18 (Debian lenny/testing), i386
PS: Please Cc me as I'm not a subscriber of the mailing list.
norbi
Re: bug candidate: replacing symlink with other symlink turns to
plain file on merge
Posted by BUCHMULLER Norbert <no...@nix.hu>.
On Sat, 13 Sep 2008 19:14:46 -0400 Karl Fogel <kf...@red-bean.com> wrote:
> This is finally fixed in r33063. Norbert, thanks again for the
> reprduction recipe. As you can see from
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3282
>
> it revealed a deeper bug in our working copy code, one that could cause
> the working copy to become unknowingly out of sync with the repository.
> It's good to get things like that fixed :-).
I'm glad that I could help. Thanks for the quick response, and the
thorough examination of the problem. I never imagined that it could have
such a deep-laying cause.. It's a good feeling to know that the
Subversion developers are thorough, careful and responsive like this.
PS: Regarding the reproduction recipe, part of the credits go for Eric
Hanchrow, as I used his reproduction recipe (posted to issue 2064) as the
base for mine.
norbi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug candidate: replacing symlink with other symlink turns to plain file on merge
Posted by Karl Fogel <kf...@red-bean.com>.
BUCHMULLER Norbert <no...@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).
This is finally fixed in r33063. Norbert, thanks again for the
reprduction recipe. As you can see from
http://subversion.tigris.org/issues/show_bug.cgi?id=3282
it revealed a deeper bug in our working copy code, one that could cause
the working copy to become unknowingly out of sync with the repository.
It's good to get things like that fixed :-).
-Karl
> 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.
>
> Subversion version: 1.5.1 (1.5.1dfsg1-1 from Debian lenny)
> O/S: Linux 2.6.18 (Debian lenny/testing), i386
>
> PS: Please Cc me as I'm not a subscriber of the mailing list.
>
> norbi
>
> ---------------------------------------------------------------------
> 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
Re: bug candidate: replacing symlink with other symlink turns to
plain file on merge
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Sep 05, 2008 at 06:50:55PM -0400, Karl Fogel 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.
>
> 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
>
I've filed this so we don't forget about it:
http://subversion.tigris.org/issues/show_bug.cgi?id=3282
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug candidate: replacing symlink with other symlink turns to plain file on merge
Posted by Karl Fogel <kf...@red-bean.com>.
"Bert Huijben (TCG)" <b....@competence.biz> writes:
> Walter Hop (from Slik) experienced about the same issue a few weeks ago.
> Polling him on his issue I learned he had created a nearly identical test
> script (http://u.lfms.nl/replacing_a_symlink.txt)
Thanks. Tell Walter it will be fixed soon :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: bug candidate: replacing symlink with other symlink turns to plain file on merge
Posted by "Bert Huijben (TCG)" <b....@competence.biz>.
> -----Original Message-----
> From: Karl Fogel [mailto:kfogel@red-bean.com]
> Sent: zaterdag 6 september 2008 6:29
> To: dev@subversion.tigris.org
> Subject: Re: bug candidate: replacing symlink with other symlink turns
> to plain file on merge
>
> Karl Fogel <kf...@red-bean.com> writes:
> > So, turns out the problem is not in the merge at all, but in the
> second
> > commit -- it never tacks on the "svn:special" property at all, even
> > though a symbolic link is being committed. Run this repro script and
> > the problem will be obvious:
>
> Btw, note that the property is still present locally. IOW, working
> copy
> and repository are out of sync afterwards :-). Nice, huh?
>
> I've added the appropriate comments to issue #3282 and assigned it to
> myself.
Walter Hop (from Slik) experienced about the same issue a few weeks ago.
Polling him on his issue I learned he had created a nearly identical test
script (http://u.lfms.nl/replacing_a_symlink.txt)
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug candidate: replacing symlink with other symlink turns to plain file on merge
Posted by Karl Fogel <kf...@red-bean.com>.
Karl Fogel <kf...@red-bean.com> writes:
> So, turns out the problem is not in the merge at all, but in the second
> commit -- it never tacks on the "svn:special" property at all, even
> though a symbolic link is being committed. Run this repro script and
> the problem will be obvious:
Btw, note that the property is still present locally. IOW, working copy
and repository are out of sync afterwards :-). Nice, huh?
I've added the appropriate comments to issue #3282 and assigned it to
myself.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug candidate: replacing symlink with other symlink turns to plain file on merge
Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
> On Fri, Sep 5, 2008 at 3:50 PM, Karl Fogel <kf...@red-bean.com> wrote:
>> 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.
(Bonus points to whoever supplies the appropriate Big Lebowski quote to
go along with the following...)
So, turns out the problem is not in the merge at all, but in the second
commit -- it never tacks on the "svn:special" property at all, even
though a symbolic link is being committed. Run this repro script and
the problem will be obvious:
--------------------------------------------------------------------------
#!/bin/sh
SVN=`which svn`
SVNADMIN=`which svnadmin`
URL=file:///`pwd`/repos
rm -rf repos wc
${SVNADMIN} create repos
${SVN} co ${URL}/ wc
cd wc
# Add two regular files in r1.
touch foo bar
${SVN} add foo bar
${SVN} ci -m "Add regular files foo, bar."
${SVN} up
# Add a symbolic link to foo in r2.
ln -s foo link
${SVN} add link
${SVN} ci -m "Add symbolic link to foo."
${SVN} up
# Change it to a symbolic link to bar in r3.
${SVN} rm link
ln -s bar link
${SVN} add link
${SVN} ci -m "Changed symbolic link to bar."
${SVN} up
LINK_URL=`${SVN} info link | grep "URL: " | cut -d " " -f2`
echo ""
echo "### But the svn:special prop didn't go into the repository in r3!"
echo "### Running 'svn plist -v ${LINK_URL}':"
echo ""
${SVN} plist -v ${LINK_URL}
echo ""
echo "### No output. Hmmm. Note that the property did make it into r2..."
echo "### Running 'svn plist -v ${LINK_URL}@2':"
echo ""
${SVN} plist -v ${LINK_URL}@2
echo ""
echo "### So the problem is with the replacing commit, not with the merge."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug candidate: replacing symlink with other symlink turns to plain file on merge
Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
> Really? I'd expect that for a 'R'eplaced file, property diffs should
> be based against the empty file, not against the deleted file.
So, the problem turns out to be deeper than we (or I, anyway) thought.
It's not related to symlinks at all.
In r32954 I committed a regression test that shows the core bug. I'm
still debugging, but since it's sleep time in my time zone, I thought
I'd post this here in case anyone else wants to have try. I *think* the
bug is ultimately in our prop-caching code... Maybe the has-props field
in .svn/entries isn't getting set at the right time? Not sure yet.
This is all issue #3282, by the way.
If you have a go, you may find the script below useful for GDB purposes
(it's the same recipe as the regression test, just with more
commentary).
--------------------------------------------------------------------------
#!/bin/sh
# The next line is the only line you should need to adjust.
SVNDIR=/home/kfogel/src/subversion
SVN=${SVNDIR}/subversion/svn/svn
SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
URL=file:///`pwd`/repos
rm -rf repos wc
${SVNADMIN} create repos
${SVN} co -q ${URL}/ wc
cd wc
touch foo
${SVN} add -q foo
${SVN} propset -q someprop someval foo
${SVN} ci -q -m "Add regular file foo, with a property." foo
${SVN} rm -q foo
# Replace it with another file of the same name.
touch foo
${SVN} add -q foo
echo ""
echo "### Okay, we've just replaced old propertied foo with a new foo"
echo "### that does not (yet) have any properties."
echo "###"
echo "### 'svn plist -v foo' on the replacement shows no property:"
echo ""
${SVN} plist -v foo
echo ""
echo "### Good."
echo ""
echo "### That's because foo's entry does not have the 'has-props' flag set."
echo "### So, in theory, foo has no props. But, suspiciously, it still"
echo "### has a prop-base/foo.svn-base file:"
echo ""
ls -l .svn/prop-base/foo.svn-base
cat .svn/prop-base/foo.svn-base
echo ""
echo "### (Shouldn't that be foo.svn-base.revert, you think? I mean,"
echo "### this file is schedule-replace now, and that's what the .revert"
echo "### files are for...)"
echo ""
echo "### Anyway, we propset the same property and value on the new foo..."
${SVN} propset -q someprop someval foo
echo "### ...and then run 'svn plist -v foo' to make sure it's there:"
echo ""
${SVN} plist -v foo
echo ""
echo "### Okay, so if we commit, new foo should go in with the property."
echo "### Let's try it. Committing..."
${SVN} ci -q -m "Replace foo, expecting property weirdness."
echo "### Done."
echo ""
echo "### After the commit, 'svn plist -v foo' still shows the property:"
echo ""
${SVN} plist -v foo
echo ""
FOO_URL=`${SVN} info foo | grep "URL: " | cut -d " " -f2`
echo "### 'svn plist -v ${FOO_URL}' does not:"
echo ""
${SVN} plist -v ${FOO_URL}
echo ""
echo "### That's very bad -- wc and repos are out of sync!"
echo ""
echo "### Just to drive the point home, look at this:"
echo ""
echo "### svn plist -v ${FOO_URL}@1:"
echo ""
${SVN} plist -v ${FOO_URL}@1
echo ""
echo "### svn plist -v ${FOO_URL}@2:"
${SVN} plist -v ${FOO_URL}@2
echo ""
cd ..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug candidate: replacing symlink with other symlink turns to plain file on merge
Posted by David Glasser <gl...@davidglasser.net>.
On Fri, Sep 5, 2008 at 3:50 PM, Karl Fogel <kf...@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 <kf...@red-bean.com> writes:
>> BUCHMULLER Norbert <no...@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@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
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug candidate: replacing symlink with other symlink turns to plain file on merge
Posted by Karl Fogel <kf...@red-bean.com>.
[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 <kf...@red-bean.com> writes:
> BUCHMULLER Norbert <no...@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@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
Re: bug candidate: replacing symlink with other symlink turns to plain file on merge
Posted by Karl Fogel <kf...@red-bean.com>.
BUCHMULLER Norbert <no...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org