Philip Martin writes:
> What I propose is that copy only produces the incomplete state for nodes
> that are copies (or copies of copies) of repository nodes. Copy would
> not produce the incomplete state for copies of added nodes. When an
> added node is copied the copy is an added note complet
"Bert Huijben" writes:
> 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.
I don't really understand the
> 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?)
I got into this state by starting
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: zaterdag 15 oktober 2011 3:29
> To: Patrick Quirk
> Cc: Philip Martin; dev@subversion.apache.org
> Subject: Re: Assertion Failed: workqueue.c
>
> Philip Martin writes:
>
Philip Martin 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
Philip Martin writes:
> Philip Martin writes:
>
>> and then running update, but I haven't yet managed to reproduce the
>> assert.
>
> Think I've got it:
I've raised issue 4035
http://subversion.tigris.org/issues/show_bug.cgi?id=4035
It looks like it's already fixed on trunk.
--
uberSVN: Apach
Philip Martin writes:
> and then running update, but I haven't yet managed to reproduce the
> assert.
Think I've got it:
svnadmin create repo
svn mkdir -mm file://`pwd`/repo/A
svn import -mm repo/format file://`pwd`/repo/A/f
svn co file://`pwd`/repo wc -r1
# insert bogus incomplete working nod
[Moving to dev]
Patrick Quirk writes:
> The 'X' folder was not and should not have been deleted or marked for
> deletion in the working copy or in the repository. The MONSTER.FMX
> folder was added beneath it and was pulled down for the first time
> during that update.
Patrick was kind enough
8 matches
Mail list logo