sanity check / paranoid option?

[Steve Suehs <cs...@drillinginfo.com>]

I've seen something strange that appears to be wc corruption.
Every once in a while we find a wc that thinks it is up-to-date but a
given file is different than its copy in a freshly-checked-out wc.
We have not been able to isolate the actions that lead up to the
condition... yet.  Usually this occurs because the developer does
something clever with find, sed/awk etc, which changes file copies in
the .svn directories.

I have noticed a pattern involving a revert and merging may come into
play as well.  I'm still trying to nail it down. It is not consistent
enough to be readily reproducible.  (Intermittent bugs are fun that
way...and it may indeed turn out to be pebcakb.)  I notice that the
checksum in the wc appears to be the same as the checksum in the fresh
copy, though the files are different, so the checksum is cached or not
recalced.

Is there a sanity check command to have the subversion client re-calc
checksums or to do a paranoid check against the repository?  Or an
alternative idea would be great, too. 

-s



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: md5sum

[Erik Huelsmann <eh...@gmail.com>]

[ Please keep mails on the list; others may be able to answer your
questions faster or better than I. ]

On 8/17/07, Steve Suehs <cs...@drillinginfo.com> wrote:
> On a fresh checkout, is it reasonable for me to expect md5sum of a file
> to match the md5sum reported by svn info?  Is it reasonable for me to be
> concerned when they do not match?

The md5 checksum you find in 'svn info' output relates to the files
you can find in the .svn area. This does not neccessarily match what
you have in your working files, because there are options which can
cause the files to be binary different. For example svn:keywords can
cause additional content to be inserted. svn:eol-style can cause
line-endings to be different from what's in the repository.

HTH,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: sanity check / paranoid option?

[Erik Huelsmann <eh...@gmail.com>]

On 8/15/07, Steve Suehs <cs...@drillinginfo.com> wrote:
> Ryan Schmidt wrote:
> > On Aug 15, 2007, at 14:56, Steve Suehs wrote:
> > > (tale of woe and pursuit of happiness)
> > Oh yes. Do not muck with the files in the .svn directory! I believe...
>
> Yes, I'm aware of that. The problem I think I am seeing does not seem to
> be related to that usual cause.

If you have known (reproducible) ways to get your working copy in a
messed up state, then we're always interested in a reproduction
recipe!

bye,

Erik

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: sanity check / paranoid option?

[Steve Suehs <cs...@drillinginfo.com>]

Ryan Schmidt wrote:
> On Aug 15, 2007, at 14:56, Steve Suehs wrote:
> > (tale of woe and pursuit of happiness)
> Oh yes. Do not muck with the files in the .svn directory! I believe...

Yes, I'm aware of that. The problem I think I am seeing does not seem to
be related to that usual cause.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: sanity check / paranoid option?

[Ryan Schmidt <su...@ryandesign.com>]

On Aug 15, 2007, at 14:56, Steve Suehs wrote:

> I've seen something strange that appears to be wc corruption.
> Every once in a while we find a wc that thinks it is up-to-date but a
> given file is different than its copy in a freshly-checked-out wc.
> We have not been able to isolate the actions that lead up to the
> condition... yet.  Usually this occurs because the developer does
> something clever with find, sed/awk etc, which changes file copies in
> the .svn directories.

Oh yes. Do not muck with the files in the .svn directory! I believe  
if the file in the text-base directory of the .svn directory has the  
same mtime as the corresponding real file, then the checksums aren't  
even checked, or something like that. And if the sed/awk completed in  
< 1 second this is what would happen.


> I have noticed a pattern involving a revert and merging may come into
> play as well.  I'm still trying to nail it down. It is not consistent
> enough to be readily reproducible.  (Intermittent bugs are fun that
> way...and it may indeed turn out to be pebcakb.)  I notice that the
> checksum in the wc appears to be the same as the checksum in the fresh
> copy, though the files are different, so the checksum is cached or not
> recalced.
>
> Is there a sanity check command to have the subversion client re-calc
> checksums or to do a paranoid check against the repository?  Or an
> alternative idea would be great, too.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: sanity check / paranoid option?

[Rainer Sokoll <R....@intershop.de>]

On Wed, Aug 15, 2007 at 02:56:17PM -0500, Steve Suehs wrote:

> condition... yet.  Usually this occurs because the developer does
> something clever with find, sed/awk etc, which changes file copies in
> the .svn directories.

This is the opposite of clever...

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org