serious 'bug'?

[Steve Franks]

I'm quite happy to report the problem appears limited to the client
box - I tried several other clients today, and they are all in sync.
I still don't know why all the other folders exist on the server but
the one in question, but the other clients think the folder is still
there on the server, and they update and commit just fine, phew.

On Sun, Mar 13, 2011 at 9:15 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 3/13/2011 2:58 PM, Steve Franks wrote:
>> Something that's supposed to 'just work' is not supposed to eat my
>> files...I'm sure it's something I 'did' as opposed to an actual bug,
>> but all I did was commit a single changed file, so it's way over my
>> head.  Then again, things are transparently broken with zero error
>> messages, so maybe it really *is* a bug.  But I'm no expert, I'm an
>> EE, not a real coder.
>>
>> This is really unbelievable.  I committed (successfully according to
>> my local terminal), and the next day I find out the folder I was
>> working in (couple levels down the tree) *disappeared* from the
>> 'server'.  It's actually still there on the 'client', so it's not like
>> I was trying to remove it.  As far as the client knows, every thing's
>> still fine.  bzr status shows 100% match between working/client and
>> server.  I can go on the server as bzr and as root, and the folder
>> really is gone.  I can add the folder from the client, and it thinks
>> it's already there.  branch.conf is clearly pointing at the server
>> like always.  I can ssh to the server and the file isn't there.  The
>> file *was* previously on the server, because all the other client
>> boxes that I use show the folder as gone (they are actually more
>> confused, because they still expect the folder to be on the server and
>> it isn't, so they barf on commit).  Also, I'm the only one using this
>> repository (although from 3 or 4 locations), so there's no outside
>> sources of corruption.
>>
>> I can't even fix this without going to a backup (maybe not even then),
>> cause all the boxes involved think their working copy is correct, but
>> none of them match.  It's a real pcloadletter kind of day.  I'm stuck
>> using gmail for version control.
>
> If you run 'bzr status', it doesn't tell you that something is out of date?

Yes, it shows the files in that folder as out-of-date

> If you run "bzr log --show-ids" do the ids match in all of the locations?

steve at fyre:~/projects/RnD$ bzr log --show-ids
bzr: failed to report crash using apport:
     OSError(13, 'Permission denied')
bzr: ERROR: bzrlib.errors.ShortReadvError: readv() read 0 bytes rather
than 181 bytes at 0 for "2ae2adc7aa3ae6d1f0a13ef93f485aeb.rix"

I get this same error on update.  Time to blow away the repository on
the dead client and start over?

> You might try "bzr update" though you should see something like "working
> tree is out of date" in "bzr status" if there is an issue.
>
>
> Note that clients generally do not update the working tree on the
> server. So the revision is probably committed, and probably available on
> the server, but the server tree has not been 'bzr update' ed to show it.

I never run any commands on the server - how are all the other folders
on the server getting 'updated'???

Also, for Eric:

steve at fyre:~/projects/RnD$ bzr missing
bzr: ERROR: No peer location known or specified.

So, my client is pretty much hosed.  Anyone have an explanation for
how this happened in the first place?

Thanks,
Steve