Currently, externals meta data is still hosted in svn:externals properties.
Information about externals is obtained by parsing these properties, just like
in 1.6. With wc-ng we have a chance to divide the actual meta data used to
manage externals internally from the interface users use to configure them.
The goal of this issue is to make internal handling of externals more
straightforward by coming up with a new clean-room design and implementation for
the externals feature (without changing the user interface part).
The way externals (file *and* directory externals) are handled in wc-ng at the
moment is problematic. It's not in a releasable state because there are
regressions from 1.6 behaviour.
For instance, it is currently impossible to flag a tree conflict on an external.
External working copies still have their own wc.db. This causes problems with
APIs such as svn_wc__db_wcroot_parse_local_abspath().
If local_abspath is the root of an external, this API will open a wcroot for the
wc.db within the external. The code flagging a conflict then tries to flag the
conflict within the nested working copy. When that is worked around (by forcing
the code flagging the conflict to open the wcroot for the parent working copy
and flag the conflict in it), additional problems pop up. For instance, svn
status fails to show the conflict on the external because it also uses
svn_wc__db_wcroot_parse_local_abspath(), opens the external's wc.db, and doesn't
see a conflict because the conflict was flagged in the parent.
This problem was exposed by the reprodcution recipe issue 3469.
It would be unwise to try to fix this by adding workarounds to all callers
of svn_wc__db_wcroot_parse_local_abspath(). Instead, we should fix the
underlying design problem.
It would be better to have a non-ambiguous representation of externals in wc.db,
with a set of new libsvn_wc APIs that can be used to manage externals, and maybe
even a new API to manage wcroots (keying wcroots on local_abspath alone is
probably a mistake!). If we do this smartly it could pave the way for managing
multiple working copies (that don't have parent->child relationships like
externals do) with a single wc.db later.
SVN-3351 can't remove file externals
SVN-3401 always block revision-fixed externals from commit
SVN-3357 Working Copy - Next Generation Library
