Hi all,
I recently encountered (and started investigating) countless problems with
file externals. I would humbly suggest that 1.7 still has poor file
externals functionality ATM, and that this as such is not releaseworthy.
But I think we could also still release and fix these things in backports,
not sure. Nevertheless, users that are on their chairs' edges waiting for
proper file externals in 1.7.0 would definitely be disappointed.
On 09/07/2011 05:52 PM, Philip Martin wrote:
> As far as I can see the fundamental problem is that
> file externals are always created at op-depth 0, even if the file
> external is locally added or copied:
The FILE_EXTERNAL column in NODES still says that it is just a dirty hack
and no-one should seriously use it. However, many places use it, because
this flag and the op_depth=0 row it is set in are necessary to distinguish
the desired file external state from the actual WC state.
Even if we relocate the FILE_EXTERNAL flag to, say, the EXTERNALS table, we
would still need some NODES row (or similar) to remember where a file
external was last checked out from, whether it is modified etc. etc.. The
EXTERNALS table tells us where the file external *should* be coming from,
and we need the NODES row to remember the current actual state (and to do
status, diff, commit,... on it almost as if it was a normal node). So I see
no easier way than having op_depth=0,file_external=1 NODES rows for
successfully checked out file externals, and special-casing code paths to
handle it properly. If you know one, enlighten me :)
Maybe we can set an op_depth=-1, but that would probably cause a lot more
special-casing of code paths than the current way.
Few details on current problems:
- wc->wc copies involving file externals
- setting file externals in locally added dir, then reverting the dir leaves
a NODES row behind for the external
- file externals in unversioned dirs are seriously broken
- most ungraceful: if the file external definition in the svn:externals prop
has a subpath that does not exist yet, svn first conveniently creates those
unversioned subdirs in your WC, puts the file external in there and then
complains about inconsistent databases or says the node does not exist, etc.
- an update on a range that removes a file external and puts a real
versioned item in its place fails (because versioned nodes are treated
before the file external can be removed). A second update is necessary.
- Before r1164027 we didn't even properly support commits on file externals
yet. That is currently waiting for backport but is being discussed in issue
4k comments.
~Neels
On 09/07/2011 05:52 PM, Philip Martin wrote:
> I was looking at the proposed backport for issue 4000 (copies of file
> externals) to 1.7 and I'm not sure it fixes the problem--all sorts of
> things don't work. As far as I can see the fundamental problem is that
> file externals are always created at op-depth 0, even if the file
> external is locally added or copied:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=4000
> http://subversion.tigris.org/issues/show_bug.cgi?id=4001
> http://subversion.tigris.org/issues/show_bug.cgi?id=4012
>
> Has anyone been using 1.7 to create/modify file externals? Is the
> current behavior good enough to release?
>
Received on 2011-09-07 23:52:04 CEST