Philip Martin <philip.martin_at_wandisco.com> writes:
> I've raised issue 4035
> It looks like it's already fixed on trunk.
Some thoughts about incomplete working nodes.
Ideally wc-to-wc copy would be a single db transaction, then we could
fail the whole copy on nodes that are impossible to copy--excluded by
the authz, incomplete, etc. This would allow us to ban incomplete
However wc-to-wc copy is currently a transaction per node, so the copy
can fail part way through. This means incomplete nodes are intrinsic to
the copy operation: when a directory is copied we add incomplete nodes
for the children. At present we add incomplete nodes for all direct
children of any copied directory.
Incomplete working nodes are a problem for the read/scan API. The
change I made for issue 4025 changes read_info so that it reports
incomplete working nodes as added, rather than incomplete, while
scan_addition reports them as incomplete. This allows us to treat
incomplete working nodes as working nodes rather than base nodes.
However it still leaves us with the problem that we lose the
One solution would be to swich to single transaction wc-to-wc copy, but
that is a lot of work. Probably easier is to tweak the existing copy
code. We distinguish between the nodes that scan_addition reports as
copied: copies of base nodes or copies of copies of base nodes, from
nodes that scan_addition reports as added: copies of added nodes. Then
we only ever add incomplete nodes for the copied nodes. That would mean
that the caller of scan_addition could treat incomplete as copied,
similar to the way an incomplete base node is treated as normal. An
itnterrupted wc-to-wc copy would show as incomplete any partially copied
repository node, but a partially copied added hierarchy would no longer
show as incomplete. I believe this means the database is correct and
Note: I'm discussing this in 1.7 terms where moved from/to doesn't
uberSVN: Apache Subversion Made Easy
Received on 2011-10-15 12:29:39 CEST