[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: Sat, 06 Sep 2008 23:19:38 -0400

"David Glasser" <glasser_at_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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-07 05:20:14 CEST

This is an archived mail posted to the Subversion Dev mailing list.