On Fri, 2005-12-09 at 13:42 -0600, kfogel@collab.net wrote:
> "Michael Pilato" <cmpilato@collab.net> writes:
> > Yep, I was seeing those, too. Took me *hours* to finally get my
> > Subversion working copy updated. You should check your versioned file
> > contents, too -- IIRC, my text-bases and working files were getting
> > filled with garbage (huge blocks of NULL bytes).
>
> Uh, whoa. This raises a larger issue, then: why didn't our checksum
> code flag these corrupt text-bases?
>
> Mike, can you describe exactly what you saw happen? If our checksum
> code isn't doing its job, that's a P1.
Unfortunately, the memory is fuzzy. I remember getting ready to commit
that big ol' tree reorg of the clients/cmdline stuff, and my commit was
out of date. So I updated, but the update died, leaving a locked
working copy. 'svn cleanup' died, too (SEGFAULTS, in
translated_stream_read, IIRC).
Thinking I landed on just the wrong revision when last I built
Subversion, and thinking that someone (was it Huelsmann? I forget...)
had been actively working on that bit of code recently, I figured I'd
manually apply patches to get me up to HEAD. The patch applied fine,
and building/installation went fine. Now I had a newer Subversion
client.
Now, I tried a clean build of Subversion, to do testing of my big reorg.
But the build failed on syntax errors which, upon inspection, were
caused by some source files having chunks of NULL bytes in them. Oddly,
'svn status' didn't report those files as having changed. It was this
that led me to assume that the working copies were hosed, but in
retrospect, it could just have been that 'svn st' was effected by the
same bug that got my working file busted in the first place.
During this time, I was raising red flags in IRC. But eventually I was
able to hand-repair my working copy, and I've not seen problems (of that
sort) since.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Fri Dec 9 22:38:32 2005