Mark,
I really doubt it is a hardware problem. I was working with
subclipse's own repository using JavaSVN adapter. What I've noticed -
some temporary files created next to the corrupted file. So, I guess it
could be somehow related to the blocked files (e.g. when compiler is
running or file is under edit/merge) when adapter can't change either
resource or .svn metadata and leave corrupted state.
If anything like that happens there should be an easy way for the user
to restore working copy, e.g. get last resource from the repository.
Am I wrong somewhere?
Eugene
Mark Phippard wrote:
> Try searching the users@subversion.tigris.org mailing list for checksum
> mismatch. I seem to recall in the past when people have posted about that
> problem that it might indicate a hardware problem. Although, I believe the
> scenario I am thinking of was a network checksum. In theory, an error like
> that is way outside of Subclipse's area. Of course, if you can find a
> specific reproduction recipe where we might consistently cause the error,
> that would be a different scenario.
>
> Also, what Subversion does once there is an error like this, is entirely up
> to it. There is nothing we can do about it in Subclipse, except stop
> causing the problem (if we are the cause). Generally, we do not touch your
> WC, we just run Subversion API's to do so.
>
> Mark
>
>
> _____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
> _____________________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
Received on Sun Nov 20 15:36:08 2005