[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

copying dirs with file externals involved

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Wed, 07 Sep 2011 23:15:10 +0200

Hi Philip,

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

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"

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").

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

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.


Received on 2011-09-07 23:15:48 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.