Re: tree-conflicts: cd into conflicted

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Sat, 29 Nov 2008 01:51:32 +0100

Sorry, clicked too fast. Here are the scripts.
(another comment, too)

Neels J Hofmeyr wrote:
> Hi tree-conflicts folks,
>
> I've made two scripts that show how a commit and an update is actually still
> attempted when inside a tree-conflicted dir. The second one shows that it is
> possible to get a tree-conflict within an already tree-conflicted dir.
>
> Currently, this doesn't weigh as heavily because having a tree-conflicted
> dir means that it was either
> - deleted in the repos. Then ci/up inside it fails because the path doesn't
> exist in the repos. Or

> - deleted in the working copy. Even though the empty directory skeleton may
> sill hang around, going into it and trying to ci will say "out of date".
> Trying to update will create another tree-conflict, because the paths have
> been removed in the repository.

I meant: "because it should fail for the same reason as its parent directory."

Hey, I haven't thought that through. Either way, It's obvious that this
shouldn't be allowed. Maybe you guys can chip in...

~Neels

>
> But if we move on to updating the wc base, this stuff might actually follow
> through with commits or updates within an already tree-conflicted subtree.
>
> However, we should block this from being tried, even before attempting to
> actually *do* a commit/update.
>
> Maybe this can wait for wc-ng, though. It is not particularly easy to run
> into this situation. We should, however, definitely mention this in the
> documentation.
>
> ~Neels
>
> Neels J Hofmeyr wrote:
>> Julian Foad wrote:
>>> On Wed, 2008-11-26 at 06:32 +0100, Neels J Hofmeyr wrote:
>>>> Hyrum K. Wright wrote:
>>>>> XFAIL: update_tests.py 50: tree conflicts on update 2.3
>>>> This one is failing for no real reason. Let me explain.
>>>> The error:
>>>> [[[
>>>> ENTERING DIR: /.../local_leaf_edit_incoming_tree_del/D/D1
>>>> CMD: svn up "" --config-dir /.../local_tmp/config --password rayjandom
>>>> --no-auth-cache --username jrandom
>>>> exited with 1
>>>> <TIME = 0.027884>
>>>> subversion/libsvn_repos/reporter.c:1162: (apr_err=160005)
>>>> svn: Target path '/local_leaf_edit_incoming_tree_del/D/D1' does not exist
>>>> ]]]
>>>>
>>>> This is an update with an incoming tree del. In English, that means that the
>>>> path D/D1 has been deleted in the repository.
>>>>
>>>> So, the target of the delete does not exist. That actually makes sense.
>>> No, I'm not sure that does make sense. "Target", to the command-line
>>> user, means the object "" to which the "update" command was applied.
>>> This directory certainly exists on disk, and it is also known to
>>> Subversion. "Target" in this error message, however, I think means the
>>> target of some repository-side operation. I haven't time to investigate
>>> now, but I suspect this is a symptom of something wrong in our code.
>>>
>>>
>>>> But the problem is, this error is only issued when going into D/D1/ in
>>>> the local working copy and running `svn up ""'.
>>>>
>>>> If going to D/ and running `svn up D1', it says, correctly, that D1 is
>>>> tree-conflicted.
>>> For clarity: it says that D1 becomes tree-conflicted by this attempt to
>>> delete it. Yes?
>> Ah sorry, I wasn't being clear. This is a situation where a tree-conflict
>> already exists. Now the test makes sure that running "svn up" skips all
>> *already* tree-conflicted nodes.
>>
>> So, if there is a tree-conflict on D/D1, D's THIS_DIR entry will have D1's
>> tree-conflict info. The case in question now is, if you cd into D/D1, then
>> run an 'svn up ""', should we go walk outwards from D/D1 to D/ (and to the
>> working copy root), to check whether any ancestor is currently
>> tree-conflicted? We'd need read locks on them too, right?
>>
>> I think eventually we'll have to do either this, or to walk the complete
>> subtree of each new tree-conflict, marking it as "tree-conflicted-ancestry"
>> or something, again removing that flag everywhere when resolving.
>>
>> Or we say: "When you have a tree-conflicted dir, don't go inside it please
>> before resolving it", well, something like that. And wait for wc-ng, where
>> hopefully it might be simpler to store such information.
>>
>> Comments??
>> ~Neels
>>
>>>> This has to be so! When going to D, we have the benefit of knowing the
>>>> tree-conflict info on D1, because it is stored in D's THIS_DIR entry.
>>>> But when within D1, and without stepping upwards in the working copy past
>>>> the current working directory, whe can't possibly know that D1 is
>>>> tree-conflicted.
>>> I would describe it as: if we are within "D1" then we can't raise a tree
>>> conflict on D1 because we don't allow ourselves to gain write access to
>>> its parent in this situation.
>>>
>>> Does that make sense?
>>>
>>> - Julian
>>>
>>>
>>>> Also imagine the case that we were at D/D1/D2/D3/D456 when D1 was the
>>>> actually deleted one that has a tree-conflict. We can't say that
>>>> D/D1/D2/D3/D456 is tree-conflicted, because there is no info in D3 about
>>>> D456. Particularly, we won't go stepping into parent dirs until we find one
>>>> that still exists and raise a conflict on its child. No, we should simply
>>>> say: "Target path '%s' does not exist". q.e.d.?
>>>>
>>>> ~Neels
>>>>
>>>>> XFAIL: switch_tests.py 21: forced switch detects tree conflicts
>>>>> XFAIL: log_tests.py 21: test log -c on range of changes
>>>>> XFAIL: log_tests.py 22: test log -c on comma-separated list of changes
>>>>> XFAIL: diff_tests.py 49: diff URL against working copy with local mods
>>>>> XFAIL: diff_tests.py 50: diff -r1 of removed file to its local addition
>>>>> XFAIL: merge_tests.py 19: merge should skip over unversioned obstructions
>>>>> XFAIL: merge_tests.py 20: merge into missing must not break working copy
>>>>> XFAIL: merge_tests.py 33: merge a replacement of a directory
>>>>> XFAIL: merge_tests.py 39: conflict from merge of add over versioned file
>>>>> XFAIL: merge_tests.py 68: mergeinfo recording in skipped merge
>>>>> XFAIL: merge_tests.py 91: merge added subtree
>>>>> XFAIL: merge_tests.py 125: merge prior to rename src existence still dels src
>>>>> XFAIL: info_tests.py 2: info on added file
>>>>> XFAIL: tree_conflict_tests.py 8: up/sw dir: add onto add
>>>>> XFAIL: tree_conflict_tests.py 14: merge dir: del/rpl/mv onto not-same
>>>>>
>>>>> Some of these may be new tests in 1.6, others might just be bad expected output,
>>>>> and yet others may be regressions from 1.5. Are there any volunteers to take a
>>>>> look at the above tests and either fix them, or classify them into one of the
>>>>> above categories so that others can fix them?
>>>>>
>>>>> Thanks,
>>>>> -Hyrum
>>>>>
>

#!/bin/bash

## GENERIC PREPARATIONS

if [ -f /usr/local/bin/superpower ]; then
  # use my local way if my script is there (neels).
  echo "##### REMEMBER TO SETUP YOUR ENVIRONMENT #####"
else
  # the rest of the world:

  # The next line is the only line you should need to adjust.
  SVNDIR=/my/svn/trunk

  alias svn=${SVNDIR}/subversion/svn/svn
  alias svnserve=${SVNDIR}/subversion/svnserve/svnserve
  alias svnadmin=${SVNDIR}/subversion/svnadmin/svnadmin
fi

svn --version

# Select an access method. If svn://, the svnserve setup is
# handled automagically by this script; but if http://, then
# you'll have to configure it yourself first.
#
# URL=http://localhost/neels/repos
# URL=svn://localhost/repos
URL=file:///`pwd`/repos

rm -rf repos wc

svnadmin create repos

# These are for svnserve only.
echo "[general]" > repos/conf/svnserve.conf
echo "anon-access = write" >> repos/conf/svnserve.conf
echo "auth-access = write" >> repos/conf/svnserve.conf

# The server will only be contacted if $URL is svn://foo, of course.
svnserve --pid-file svnserve-pid -d -r `pwd`
# And put the kill command in a file, in case need to run it manually.
echo "kill -9 `cat svnserve-pid`" > k
chmod a+rwx k

svn co -q ${URL} wc

set -x
cd wc

## ACTUAL TEST

# Original Java package (entirely fictional).

mkdir -p dir/ect/ory
cat > dir/ect/ory/file <<END
some file
END

svn add dir
svn ci -m "initial commit"

# now at rev 1

svn rm dir
svn ci -m "rev 2"

# back to 1
svn up -r 1

svn propset foo foo-val dir
svn up
svn st
svn info dir

echo x >> dir/ect/ory/file
cd dir/ect
# this commit shouldn't even open a log message editor.
svn ci
svn up
cd ../..

## ACTUAL TEST ENDS
echo "====="
cd ..

pwd
./k