On Wed, Nov 16, 2011 at 2:03 AM, Philip Martin
<philip.martin_at_wandisco.com>wrote:
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
> >> I hate to confess to such absent mindedness, but I may have "svn
> delete"ed
> >> this file. I see that I don't have a local copy of it, which supports
> that
> >> theory. If I did that, I didn't commit the change -- the repository
> still
> >> has the file.
> >
> > I'll have to think about that.
>
> This does explain some things. The client is not adding or modifying
> the file due to any change sent from server, it is merely restoring the
> missing file from its own metadata. That's a small step forward in
> understanding the problem.
>
> It's still not clear how the upgrade went wrong. It's not as simple as
> "svn rm file", "svn upgrade", "svn update" as that works (and would have
> created an op_depth>0 nodes row that we didn't see in the very first
> query you ran).
>
Yes, I tried that myself with a sub-directory including exactly the same
file.
>
> Perhaps it's something to do with the moved file? Perhaps you did
> something like:
>
> svn rm file-before-mv # or perhaps a mv?
>
Definitely no mv. Maybe an rm.
> # some other wc moves and commits the file
>
I'm pretty sure this isn't the case. There's been no activity for this
file since January, and I've done many global check-ins where I'd have
noticed local changes if I'd made them before January.
> svn update # getting a delete/delete tree conflict
> svn resolved # or revert?
> rm file-after-mv # a non-svn rm
> svn upgrade
>
> Perhaps you had two files with the same checksum (that's legitimate) and
> that caused the upgrade to fail? I'll experiment and see if I can
> reproduce it.
>
That is quite possible. This was a large sub-directory with many files.
Another thing which is unusual about our use of SVN is several very
large(~20MB) text files, though the particular file we've been
concentrating on was quite small.
>
> --
> Philip
>
Received on 2011-11-16 17:58:20 CET