On Wed, Nov 16, 2011 at 2:03 AM, Philip Martin <philip.mar...@wandisco.com>wrote:
> Philip Martin <philip.mar...@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 >
