[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: nasty commit bug

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-07-12 20:25:01 CEST

Karl Fogel <kfogel@newton.ch.collab.net> writes:
> > OK, it looks like the hash lookup has returned NULL, that should not
> > happen. However the commit has already been sent to the server so I
> > don't think this can be responsible for the corruption.
> Yeah. We *seriously* need a repro case for this right now...

Pilchie, maybe we can make a repro case using your working copy, which
has already been known to have a problem at least once.

First, run

   $ svn st -v

on that working copy. I know you've already made the commit, but you
haven't committed anything *since* then, I assume, and we know what
local mods you intended to make, so if we have

   1. Your "svn st -v" output
   2. A patch giving the local mod you meant to commit

... then we can probably reconstruct your working copy at the time you
committed, and thus reconstruct your working copy as it was before the

The hard part is that we don't know if your text bases were corrupted
before the commit or not. But, if those two text bases were
corrupted, chances are others were too. So, *after* doing the above,
could you do this:

   $ find . -name "*.[ch]" | xargs touch
   $ svn st -v
   $ svn diff

That will invalidate all your timestamps, forcing a text-base
comparison for the working files. If anything looks different here,
we may have a lead.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 12 20:36:25 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.