copying dirs with file externals involved

[Neels J Hofmeyr <ne...@elego.de>]

Hi Philip,

I am responding to your 3rd comment in issue #4000:

http://subversion.tigris.org/issues/show_bug.cgi?id=4000#desc5
[[[
If I set svn:externals in the copy and then run "svn up" I see a NODES row at
op_depth 0:

$ svn ps svn:externals '^/A/f g' wc/B
$ svn up wc
$ sqlite3 wc/.svn/wc.db "select op_depth, local_relpath, presence, file_external
from nodes"
0|A/f|normal|
0|A|normal|
0|A/h|normal|1
1|B|normal|
1|B/h|incomplete|
1|B/f|normal|
0||normal|
0|B/g|normal|1

I don't think that is right, how would it work if B was a replace and B/g
already existed?

The B/g row gets left behind by "svn revert -R".
]]]

Hmm, the external row being left behind after "svn revert -R" is indeed a
failure. Tricky. But such op_depth=0 row in a locally added dir for a file
external per se is otherwise not a problem AFAICT.

I tested through a multitude of cases, and almost [1] all work fine. The
FILE_EXTERNAL flag on such a row successfully avoids any faulty commits, and
as long as non-f'extl BASE nodes are around, even if the node is locally
deleted (== additional base-deleted at op_depth>0), no file externals are
brought in ("cannot overwrite the existing versioned item").

[1]:
Where this really gets interesting is when you locally remove a dir with a
file external in it -- the f'extl gets a base-deleted NODE row at op_depth >
0; interesting, but upon commit is treated correctly. (in all cases?)

[[[
svn ps svn:externals "^/file xfile" A
svn ci -mm
svn up

svn rm A
sqlite3...
...
A/xfile|0|normal|1
A/xfile|1|base-deleted|
...

svn ci -mm
# all ghosts have vanished
]]]


Definitely buggy is the case where, after removing a dir with a file
external in it, copying another dir with another file external at the same
resulting local path over it, and running 'svn update' in that situation:

[[[
svn ps svn:externals "^/file xfile" A
svn ps svn:externals "^/file2 xfile" B
svn ci -mm
svn up

svn rm A
svn cp B A

svn update
Fetching external item into 'A/xfile':
...workqueue.c' line 672: assertion failed (checksum != NULL)".
]]]


So there's a case where a file external row is left behind by revert.
And there's a problem with locally replacing file externals via their parent
dirs. Will probably investigate, but should be separate issues.

Thanks for spotting the incompleteness of the #4000 fix! That's first on my
list now.

~Neels