You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by John Szakmeister <jo...@szakmeister.net> on 2007/05/31 12:26:45 UTC
Re: Invalid diff stream: insn 4 cannot be decoded
----- "Chuck Berg" <Ch...@unlv.edu> wrote:
[snip]
> Any new insights from anyone?
Wrong list: users@subversion.tigris.org is the one you want. This list is only about development of Subversion.
That said, fsfsverify may help you:
http://www.szakmeister.net/fsfsverify/
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Invalid diff stream: insn 4 cannot be decoded
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Szakmeister wrote:
> Daniel Rall wrote:
>> On Thu, 31 May 2007, John Szakmeister wrote:
>>
>>> ----- "Chuck Berg" <Ch...@unlv.edu> wrote:
>>> [snip]
>>>> Any new insights from anyone?
>>> Wrong list: users@subversion.tigris.org is the one you want. This
>>> list is only about development of Subversion.
>>>
>>> That said, fsfsverify may help you:
>>> http://www.szakmeister.net/fsfsverify/
>>
>> Are we bundling some version of fsfsverify with Subversion's source
>> yet (e.g. in contrib)?
>
> C-Mike actually sent me a private mail about the same thing. I guess I
> have a few reservations:
> 1) I don't have much time to maintain fsfsverify. It's sporadic at
> best, and I feel that putting something in contrib/ was a sign that
> I was willing to maintain it.
>
> 2) I feel like having fsfsverify in the contrib/ makes it easy to fix
> broken revs... but also helps to mask the issue. Many more users
> have downloaded fsfsverify than have contacted me. Even fewer
> have offered any sort of help, if that provides any sense of the
> problem. That said, I see the other side of the story too--it's
> costly for a business to have downtime--which is why it exists on my
> site.
>
> 3) I didn't want to have a script out there, in everyone's face so that
> some moron could along and say: "Hey look, Subversion is so bad,
> that this dude wrote a script to practically automate fixing broken
> revs."
>
> C-Mike countered both 1) stating that "putting it in contrib/ allows
> others to more easily work on it." I buy that. He also countered 3)
> and said "Bad things happen, and not always because the primary software
> is buggy." I buy that too... though I don't think fsfsverify will be
> much help in those cases in its current state. *shrug* I suppose
> someone could help expand on its current capabilities though.
>
> My real issue at the moment is 2). I feel like this corruption issue
> has been out there forever. Partly because it doesn't happen that often
> (relatively speaking), partly because fsfsverify is an easy way to get
> back up and running and get along with life. Only those that have been
> seriously irritated by the problem have bothered to chime in and help
> look at the problem a little more in-depth.
>
> So, my question back to the community is, am I out of my mind? :-) And,
> do you see more value in having it in contrib/ than not? If so, I'll
> put I'll happily put fsfsverify in the contrib/ area. Again, my big
> concern is masking the issue rather than fixing it... although--and I
> think Malcolm would agree--this has been a rather nasty issue to track
> in general.
You know my vote: +1 on adding it to contrib
As for (2), the presence or absence of fsfsverify in the tree is not going
to really affect whether or not people spend time debugging the issue.
You've made fsfsverify public, and folks searching for FSFS corruption will
find it on your site or ours, or get it sent to them via somebody on users@,
or -- they're going to get their hands on fsfsverify regardless. And yes,
their primary motive will be a selfish "get myself back online NOW" rather
than the more community-minded "how can I help fix this bug so others don't
suffer". But that's human nature, and (again, because fsfsverify is public)
at this point largely unavoidable. Your conscience is off the hook, man.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Invalid diff stream: insn 4 cannot be decoded
Posted by John Szakmeister <jo...@szakmeister.net>.
Daniel Rall wrote:
> On Thu, 31 May 2007, John Szakmeister wrote:
>
>> ----- "Chuck Berg" <Ch...@unlv.edu> wrote:
>> [snip]
>>> Any new insights from anyone?
>> Wrong list: users@subversion.tigris.org is the one you want. This list is only about development of Subversion.
>>
>> That said, fsfsverify may help you:
>> http://www.szakmeister.net/fsfsverify/
>
> Are we bundling some version of fsfsverify with Subversion's source
> yet (e.g. in contrib)?
C-Mike actually sent me a private mail about the same thing. I guess I
have a few reservations:
1) I don't have much time to maintain fsfsverify. It's sporadic at
best, and I feel that putting something in contrib/ was a sign that
I was willing to maintain it.
2) I feel like having fsfsverify in the contrib/ makes it easy to fix
broken revs... but also helps to mask the issue. Many more users
have downloaded fsfsverify than have contacted me. Even fewer
have offered any sort of help, if that provides any sense of the
problem. That said, I see the other side of the story too--it's
costly for a business to have downtime--which is why it exists on my
site.
3) I didn't want to have a script out there, in everyone's face so that
some moron could along and say: "Hey look, Subversion is so bad,
that this dude wrote a script to practically automate fixing broken
revs."
C-Mike countered both 1) stating that "putting it in contrib/ allows
others to more easily work on it." I buy that. He also countered 3)
and said "Bad things happen, and not always because the primary software
is buggy." I buy that too... though I don't think fsfsverify will be
much help in those cases in its current state. *shrug* I suppose
someone could help expand on its current capabilities though.
My real issue at the moment is 2). I feel like this corruption issue
has been out there forever. Partly because it doesn't happen that often
(relatively speaking), partly because fsfsverify is an easy way to get
back up and running and get along with life. Only those that have been
seriously irritated by the problem have bothered to chime in and help
look at the problem a little more in-depth.
So, my question back to the community is, am I out of my mind? :-) And,
do you see more value in having it in contrib/ than not? If so, I'll
put I'll happily put fsfsverify in the contrib/ area. Again, my big
concern is masking the issue rather than fixing it... although--and I
think Malcolm would agree--this has been a rather nasty issue to track
in general.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Invalid diff stream: insn 4 cannot be decoded
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 31 May 2007, John Szakmeister wrote:
>
> ----- "Chuck Berg" <Ch...@unlv.edu> wrote:
> [snip]
> > Any new insights from anyone?
>
> Wrong list: users@subversion.tigris.org is the one you want. This list is only about development of Subversion.
>
> That said, fsfsverify may help you:
> http://www.szakmeister.net/fsfsverify/
Are we bundling some version of fsfsverify with Subversion's source
yet (e.g. in contrib)?