On Tue, Nov 15, 2011 at 4:28 PM, Philip Martin
<philip.martin_at_wandisco.com>wrote:
> Ethan Bradford <ethan.bradford_at_swype.com> writes:
>
> >> sqlite3 .svn/wc.db "select * from work_queue"
> >
> > 3|(file-install 59
> > DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED] 1 0 1 1)
> >
> >> sqlite3 .svn/wc.db "select * from nodes where
> >
> local_relpath='DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]'"
> >
> >
> 1|DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|0|DBBuild/Wordlists/Belarusian|1|Trunk/DBBuild/Wordlists/Belarusian/BelarusianForceFreq.txt[MOVED]|3936|normal|||file||infinity|||3323|1294867663142001|Erik.Larsson|504|1294985508149158||
> >
> > So there's no checksum (according to other entries, it would be the field
> > just after "infinity").
>
> That's very odd. Do you know which version of Subversion is running on
> the server? Running something like "curl -D - REPO_URL" might help find
> out.
>
I don't know what the server version is. cURL won't accept an svn: URL.
I can't figure out how to get the version out of the "repro browser",
which is the most direct serverconnection in the toolset I know.
>
> Are there other files with no checksum?
>
> sqlite3 .svn/wc.db "select count(*) from nodes where checksum is null and
> kind='file'"
>
The answer to that query is "1", so that's the only pattern. (Old
fashioned searches through the dumped list of nodes confirms this.)
>
> If there are other files then is there any pattern in the filenames?
> All in the same directory? All modified in the same commit? etc.
>
> sqlite3 .svn/wc.db "select local_relpath from nodes where checksum is null
> and kind='file'"
>
>
> Can you describe the recent activity in the working copy? Do you
> normally update the whole working copy or do you update subtrees?
Normally I update a large subtree (several levels up from this file).
> Did
> you commit changes in the Belarusian directory just before the update?
>
No, I haven't committed changes from that directory in months. Nobody else
has either.
>
> The NODES row shows that the update was trying to install revision 3936
> of the file. The filename is "BelarusianForceFreq.txt[MOVED]"; has this
> file been moved/copied within the repository?
We moved these files to another repository, so that SVN couldn't (as far as
we could figure out) understand the move. So we renamed the the files on
the source side to keep their history conveniently available.
> The last modified
> revision of the file is 3323, would you have committed that revision
> from this working copy?
>
That is the last revision, and I didn't commit it from this computer. (It
was inf
>
> Do you know the revision before the update? It's possible that you can
> identify it using
>
> sqlite3 .svn/wc.db "select revision from nodes where revision != 3936"
>
> or perhaps
>
> sqlite3 .svn/wc.db "select revision from nodes where
> parent_relpath='DBBuild/Wordlists/Belarusian'"
>
> or perhaps you can guess the approximate revision based on dates?
>
> If you can identify the (approx?) revision before the update then
> running "svn log -vq URL" will allow you to see the sort of changes the
> update would have been making. I want to know what the update did to
> this file, did it just modify the content of the file, or add the file,
> or replace another file of the same name? Perhaps the whole directory
> was being added?
>
Using the repo browser I can see the whole history. There are just two
versions of this file, none more recent than 3323. I think 3936 is a red
herring -- that was perhaps the tip revision for the whole repository when
the update was attempted. (The current tip is 4013.)
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.
> Thanks for your help so far!
>
I'm happy to help, and I appreciate your time. Just to be clear, I
wouldn't dream of taking so much of your time just to solve my local
problem. You're digging into this to figure out the bug with change to the
1.7.1 version (or maybe "svn update" within the 1.7.1 version), right?
Since I will likely need to do another checkout anyhow, I'm happy to try
experiments which might be destructive to my local copy.
> --
> Philip
>
Received on 2011-11-16 02:21:51 CET