> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: zaterdag 15 oktober 2011 3:29
> To: Patrick Quirk
> Cc: Philip Martin; dev_at_subversion.apache.org
> Subject: Re: Assertion Failed: workqueue.c
>
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
> > I've raised issue 4035
> > http://subversion.tigris.org/issues/show_bug.cgi?id=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
> working nodes.
>
> 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
> added/copied difference.
>
> 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
> valid.
How can you recover from this state?
Can you delete the incomplete node? (It's parent?) or is the only way to
recover to revert the root of the copy operation?
If only that last case is true I wouldn't call it a defined database state.
Another question: Did the reporters get here by doing a copy and then
cancelling, or did they perform an upgrade of a copied tree?
(I missed the verification of this on the mailing list. Maybe the current
user problem is in the upgrade/write entries code?)
Bert
Received on 2011-10-15 15:37:10 CEST