Hi Vijay,

I gave that patch a spin (after all I was the one who brought
--include-externals upon us), and found stuff. Using current trunk + your
patch v3.

BTW, I'm sorry to have to drag this patch submission out; countless times I
myself tried to just quickly fix a small externals quirk and it ended up
sticking to my fingers for weeks. Don't give up! ;)

There's a small thing and a more complex one.

(1) 'svn list' normally only lists the current dir level unless -R is
supplied. So --include-externals should actually only print the externals
dirnames, and step into them only with -R also supplied. Right?

That was the small thing.


(2)
I'm comparing
 svn list --include-externals
with
 svn list ./external-target-dir/

After removing and committing a file inside an external, there is a
difference between above invocations:

(test script also attached)
[[[
# prepare an external dir...
mkdir a
echo a > a/file
echo b > b
svn add a b
svn propset svn:externals "^/a x1" .
svn ci -mm
svn up

# remove a file and commit inside external dir
svn rm x1/file
svn ci -mm x1

svn list --include-externals
# a/
# b
# Listing external 'x1' defined on 'file:///tmp/trunk.qLP/repos':

svn list x1
# file

## ^ difference: 'list x1' still shows 'file'

# comparison: 'list' behavior when no external is involved
# a normal deleted file is still shown, until next update.
svn rm b
svn ci -mm
svn list
# a/
# b
]]]
(After the next update, all invocations don't show the deleted file anymore,
obviously.)

I expected 'list --include-externals' to act exactly like 'svn list x1/',
but there is a slight difference. I suspect that 'svn list x1/' takes
advantage of the WC at x1/ already present locally, and that 'svn list
--include-externals' goes directly to the repos URL. Is that right?
Maybe 'svn list --include-externals' should limit to listing strictly only
those externals currently checked out (unless the target itself is a URL).
I.e. if the target is a working copy, traverse the WC for checked out
externals and maybe even feed the local external WC paths as explicit
targets to svn_client_list3() or something ... ?


Good speed!
~Neels
#!/usr/bin/env bash

## TO MAKE THIS RUN YOUR CUSTOM COMPILED SVN, two simple options:
## 1. Adjust your PATH to point at your custom installed location:
##      export PATH="$HOME/prefix/svn_trunk/bin:$PATH"
## OR
## 2. Uncomment the four lines below to use aliases into your
##    built source tree. The next line is the only line you should
##    need to adjust.
# SVNDIR=/path/to/built_subversion_source_tree
# function svn() { "$SVNDIR/subversion/svn/svn" "$@"; }
# function svnserve() { "$SVNDIR/subversion/svnserve/svnserve" "$@"; }
# function svnadmin() { "$SVNDIR/subversion/svnadmin/svnadmin" "$@"; }

set -e

svn --version
BASE="`mktemp -d /tmp/trunk.XXX`"
echo "BASE = $BASE"
REPOS="$BASE/repos"
WC="$BASE/wc"
URL="file://$REPOS"
svnadmin create "$REPOS"

# enable all revprop changes
cat > "$REPOS/hooks/pre-revprop-change" <<EOF
#!/usr/bin/env sh
exit 0
EOF
chmod a+x "$REPOS/hooks/pre-revprop-change"

svn co -q "$URL" "$WC"

set +e
set -x
cd "$WC"

## ACTUAL TEST

# prepare an external dir...
mkdir a
echo a > a/file
echo b > b
svn add a b
svn propset svn:externals "^/a x1" .
svn ci -mm
svn up

# basic check
svn list --include-externals
svn list --include-externals -R
svn list x1

# remove a file and commit inside external dir
svn rm x1/file
svn ci -mm x1
svn list --include-externals
svn list x1

# comparison: 'list' behavior when no external is involved
svn rm b
svn ci -mm
svn list

# after update...
svn up
svn list --include-externals
svn list x1

## END
set +x
echo "BASE = $BASE"

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to