You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by solo turn so...@yahoo.com on 2003/01/25 15:58:42 UTC
checksumming crap
it seems that checksumming is ill:
in wc1:
$ svn mv b b1
$ svn st
D b
D b/aaf.txt
D b/bb
D b/bb/bbb
D b/bb/bbc
D b/bb/bbc/bbba.txt
D b/bb/bbc/bbbb
D b/bb/bbf.txt
D b/bb/klu.java
A + b1
? b1/bb/bbe.txt
$ svn add b1/bb/bbe.txt
in wc2, after checking in in wc1:
$ svn up
A b1
A b1/bb
A b1/bb/bbb
A b1/bb/bbe.txt
A b1/bb/bbc
svn: A checksum mismatch occurred
svn: apply_window: checksum mismatch after applying text delta
(b1/bb/bbc/.svn/tmp/text-base/bbba.txt.svn-base):
expected checksum: 34f9383e157bc6305f4c7e2290d6ac39
actual checksum: d41d8cd98f00b204e9800998ecf8427e
$ svn --version
svn, version 0.17.1 (dev build)
compiled Jan 25 2003
generally i'm VERY concerned about the .svn folder. it is a system
directory, and it is never the master. it has to be treated like that
(i.e. fixed automatically).
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reconstruct .svn (was Re: checksumming crap)
Posted by Greg Hudson gh...@MIT.EDU.
On Sat, 2003-01-25 at 13:01, solo turn wrote:
visual source safe does not have an entry file and it works.
Without knowledge of VSS's design, this is a meaningless statement.
Maybe VSS remembers checkouts on the repository, like Perforce does.
Maybe VSS doesn't work very well. Maybe it squirrels entry file data
into some other location like the registry.
The fact remains: without a base revision, you can't perform an update
operation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
reconstruct .svn (was Re: checksumming crap)
Posted by solo turn so...@yahoo.com.
you know your real directory, and you know your directory in the
repository. that is sufficient to reconstruct the entries file.
visual source safe does not have an entry file and it works.
--- Justin Erenkrantz jerenkrantz@apache.org wrote:
--On Saturday, January 25, 2003 9:26 AM -0800 solo turn
soloturn99@yahoo.com wrote:
but the .svn can be recreated. and the wc can be fixed by merging
in
the changes if something is there, or by just recreating the
files/folders.
No, it can't be recreated automatically.
Without the .svn/entries file, there is no way for Subversion to
know
anything about the directory. -- justin
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Justin Erenkrantz je...@apache.org.
--On Saturday, January 25, 2003 9:26 AM -0800 solo turn
soloturn99@yahoo.com wrote:
but the .svn can be recreated. and the wc can be fixed by merging in
the changes if something is there, or by just recreating the
files/folders.
No, it can't be recreated automatically.
Without the .svn/entries file, there is no way for Subversion to know
anything about the directory. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reconstruct .svn (was: Re: checksumming crap)
Posted by Greg Hudson gh...@MIT.EDU.
On Sat, 2003-01-25 at 13:12, solo turn wrote:
i want to get the difference between HEAD and wc into the wc.
using a 2-way-merge, the revision 100 is not important to me as end
user.
A two-way merge between wc and head is a radically different operation
from the usual three-way merge performed by an update. It is much less
automated--it would require you to manually review every difference
between the wc and the head and remember it that difference reflects a
local change in your working copy or a change in the repository.
It's possible that you, personally, as an end user, want Subversion to
fall back on this kind of merging when it can't determine the base
revision. But that does not justify the kind of complexity it would
require for us to support it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
reconstruct .svn (was: Re: checksumming crap)
Posted by solo turn so...@yahoo.com.
i want to get the difference between HEAD and wc into the wc.
using a 2-way-merge, the revision 100 is not important to me as end
user.
i mean, i know(100 in your example, i could also do a 3-way merge) or
assume (HEAD if i don't know any better) a base revision.
--- Greg Hudson ghudson@MIT.EDU wrote:
On Sat, 2003-01-25 at 12:26, solo turn wrote:
but the .svn can be recreated. and the wc can be fixed by merging
in
the changes if something is there, or by just recreating the
files/folders.
Uh, no. You can't merge in the changes without a base revision.
For
example:
% svn co -r 100 url foo
% cd foo
% svn cat -r 50 bar bar
% dd if=/dev/random of=.svn/entries bs=1k count=10
% svn update bar
How is Subversion supposed to know what to do here? The right
answer is
to merge the differences between rev 100 and rev HEAD of bar into
the
current contents (which are the contents of rev 50), but you've
taken
away the knowledge that rev 100 is the starting point.
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Greg Hudson gh...@MIT.EDU.
On Sat, 2003-01-25 at 12:26, solo turn wrote:
but the .svn can be recreated. and the wc can be fixed by merging in
the changes if something is there, or by just recreating the
files/folders.
Uh, no. You can't merge in the changes without a base revision. For
example:
% svn co -r 100 url foo
% cd foo
% svn cat -r 50 bar bar
% dd if=/dev/random of=.svn/entries bs=1k count=10
% svn update bar
How is Subversion supposed to know what to do here? The right answer is
to merge the differences between rev 100 and rev HEAD of bar into the
current contents (which are the contents of rev 50), but you've taken
away the knowledge that rev 100 is the starting point.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by solo turn so...@yahoo.com.
--- Greg Hudson ghudson@MIT.EDU wrote:
On Sat, 2003-01-25 at 11:24, Justin Erenkrantz wrote:
generally i'm VERY concerned about the .svn folder. it is a
system
directory, and it is never the master. it has to be treated
like
that (i.e. fixed automatically).
Huh? This paragraph doesn't parse at all. -- justin
He's saying all the data under .svn can be recreated from the
repository, and that we should handle detected corruption by
regenerating the data instead of blowing out. But the premise
isn't
really true; the repository has no idea what revs of files and
directories you have checked out.
this is as true as unimportant. i could have changed anything or
thrown away anything. the repository does not know.
but the .svn can be recreated. and the wc can be fixed by merging in
the changes if something is there, or by just recreating the
files/folders.
that's what a svn up is for.
otherwise we should rename it to svn check, or svn integrity.
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Greg Hudson gh...@MIT.EDU.
On Sat, 2003-01-25 at 11:24, Justin Erenkrantz wrote:
generally i'm VERY concerned about the .svn folder. it is a system
directory, and it is never the master. it has to be treated like
that (i.e. fixed automatically).
Huh? This paragraph doesn't parse at all. -- justin
He's saying all the data under .svn can be recreated from the
repository, and that we should handle detected corruption by
regenerating the data instead of blowing out. But the premise isn't
really true; the repository has no idea what revs of files and
directories you have checked out.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Lele Gaifax le...@seldati.it.
On Sun, 26 Jan 2003 03:31:19 +0100, Lele Gaifax lele@seldati.it said:
LG Argh, the new client receives a plonk from the old dav,
LG although an svn st works
Ah, of course it does, since st does not involve the server, but st
-u fails.
yes, I'm coming!
'night, lele.
--
nickname: Lele Gaifax | Quando vivr� di quello che ho pensato ieri
real: Emanuele Gaifas | comincer� ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Karl Fogel kf...@newton.ch.collab.net.
Michael Wood mwood@its.uct.ac.za writes:
He means ra_svn, but the has no entries file is probably also valid :)
A subsequent svn cat |
diff shows no differences ;-)
Ahh, okay, you can 'svn cat', so that probably means you downgraded
your client back to 0.16.1, right?
[snip]
I suspect he means that svn cat over ra_svn works.
Thanks -- yeah, I just didn't notice the schema change.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Michael Wood mw...@its.uct.ac.za.
On Mon, Jan 27, 2003 at 06:07:30PM -0600, Karl Fogel wrote:
Lele Gaifax lele@seldati.it writes:
[snip]
$ svn co svn://caia/Scarambol .
...
Checked out revision 17.
$ cd p/Documenti
$ cp ~/Scarambol/Documenti/Statuto_SCR_Compatto.lyx .
$ svn st
M StatutoSCR_Compatto.lyx
$ svn ci -m Reso su due colonne, eliminata la lista dei fondatori StatutoSCR_Compatto.lyx
Sending StatutoSCR_Compatto.lyx
Transmitting file data .
Committed revision 18.
as expected, since svn doesn't use checksums.
svn doesn't use checksums == has no entries file to compare,
right?
He means ra_svn, but the has no entries file is probably also valid :)
A subsequent svn cat |
diff shows no differences ;-)
Ahh, okay, you can 'svn cat', so that probably means you downgraded
your client back to 0.16.1, right?
[snip]
I suspect he means that svn cat over ra_svn works.
--
Michael Wood mwood@its.uct.ac.za
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Karl Fogel kf...@newton.ch.collab.net.
Lele Gaifax lele@seldati.it writes:
I do not understand if this is
expected, although I guess it isn't (or is entries::checksum
reflecting the *actual* md5 of the *working copy*??)
It always reflects the text base (as you supposed).
So far I'm unable to reproduce the bug myself, using the recipe you
listed:
KF Thanks for the detailed report. With patience I hope we can
KF work out a reproduction recipe for this...
Well, I do not seem to repeat myself here, having nothing new to add,
if not a doubt. Let me redraw the situation that lead to the error:
a. svn cp existing-file new-file
b. svn commit new-file
c. lyx new-file
without errors. At this point I have that in the .svn/text-base dir I
find, as I expected, two identical files, existing-file.svn-base and
new-file.svn-base. But in the entries, I find that the checksum
for the existing-file matches, while that of new-file does not,
and it is not the md5sum of neither newfile nor that of
.svn/text-base/newfile.svn-base.
On the other hand, as part of investigating this, I discovered and
filed
http://subversion.tigris.org/issues/show_bug.cgi?id=1120
...which is nice :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Lele Gaifax <le...@seldati.it> writes:
> I do not understand if this is
> expected, although I guess it isn't (or is entries::checksum
> reflecting the *actual* md5 of the *working copy*??)
It always reflects the text base (as you supposed).
So far I'm unable to reproduce the bug myself, using the recipe you
listed:
> KF> Thanks for the detailed report. With patience I hope we can
> KF> work out a reproduction recipe for this...
>
> Well, I do not seem to repeat myself here, having nothing new to add,
> if not a doubt. Let me redraw the situation that lead to the error:
>
> a. svn cp existing-file new-file
> b. svn commit new-file
> c. lyx new-file
>
> without errors. At this point I have that in the .svn/text-base dir I
> find, as I expected, two identical files, "existing-file.svn-base" and
> "new-file.svn-base". But in the "entries", I find that the checksum
> for the "existing-file" matches, while that of "new-file" does not,
> and it is not the md5sum of neither "newfile" nor that of
> ".svn/text-base/newfile.svn-base".
On the other hand, as part of investigating this, I discovered and
filed
http://subversion.tigris.org/issues/show_bug.cgi?id=1120
...which is nice :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Lele Gaifax le...@seldati.it.
[Sorry Karl for the repost, this was for the list...]
On 27 Jan 2003 18:07:30 -0600, Karl Fogel kfogel@newton.ch.collab.net said:
recorded checksum: f86e0240984a0240d81d0908a01d0908 actual
checksum (hex): cb6161ca16f9984bd26b25a07c1f6b15 actual
checksum (base64): y2Fhyhb5mEvSayWgfB9rFQ==
KF Okay, you must have been running a dev build somewhat past
KF 0.16.1, or you would have seen a different error text here.
KF Furthermore, the recorded checksum would have been in base64,
KF since we didn't start recording checksums in hex until after
KF 0.16.1.
Yes, I said that at the beginning of my post.
Ok, so now I have the latest client: $ svn --version svn,
version 0.17.1 (dev build) compiled Jan 26 2003, 02:55:40
and I repeat the last commit, that as I was supposing it emits
the very same message
KF Okay, at least it's behaving consistently. Somehow the text
KF base has gotten corrupted, it seems. Are there any properties
KF on this file? Can you run 'svn pl -v StatutoSCR.lyx
KF StatutoSCR_Compatto.lyx' and post the output?
No, I do not use properties (yet :); that workingdir is locked (I
haven't updated the mod_dav on server :/) so I cannot check to be sure
110%: checking out a copy via svn:// confirms that there aren't
properties involved.
I'm tired, and will go on tomorrow on the server side. But as a
last try, I:
$ cd /tmp $ mkdir p $ cd p $ svn co svn://caia/Scarambol . ...
Checked out revision 17. $ cd p/Documenti $ cp
~/Scarambol/Documenti/Statuto_SCR_Compatto.lyx . $ svn st M
StatutoSCR_Compatto.lyx $ svn ci -m Reso su due colonne,
eliminata la lista dei fondatori StatutoSCR_Compatto.lyx
Sending StatutoSCR_Compatto.lyx Transmitting file data .
Committed revision 18.
as expected, since svn doesn't use checksums.
KF svn doesn't use checksums == has no entries file to
KF compare, right?
Sorry, I do not understand here. I meant, using svnserve on the server
does not involve the same amount of checksum checking, does it?
A subsequent svn cat | diff shows no differences ;-)
KF Ahh, okay, you can 'svn cat', so that probably means you
KF downgraded your client back to 0.16.1, right?
KF So what exactly was the diff command above? Without knowing
KF what you were comparing (working file? text base?), it
KF doesn't mean much.
No, the newer client cannot talk with svn_dav 0.16.0, so I extracted a
new wc via svn:// and committed the new revision of the file from
there, then extracted a copy of the doc with svn cat svn://... and
diffed against the committed version. It was just to be able to fall
asleep, knowing my changes were stored in the same order i did them :)
KF Thanks for the detailed report. With patience I hope we can
KF work out a reproduction recipe for this...
Well, I do not seem to repeat myself here, having nothing new to add,
if not a doubt. Let me redraw the situation that lead to the error:
a. svn cp existing-file new-file
b. svn commit new-file
c. lyx new-file
without errors. At this point I have that in the .svn/text-base dir I
find, as I expected, two identical files, existing-file.svn-base and
new-file.svn-base. But in the entries, I find that the checksum
for the existing-file matches, while that of new-file does not,
and it is not the md5sum of neither newfile nor that of
.svn/text-base/newfile.svn-base. I do not understand if this is
expected, although I guess it isn't (or is entries::checksum
reflecting the *actual* md5 of the *working copy*??)
well, that's it I'm afraid, I cannot see both 4am and 8:30am for too
days in a row :|
byethanx,
lele.
--
nickname: Lele Gaifax | Quando vivr� di quello che ho pensato ieri
real: Emanuele Gaifas | comincer� ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Karl Fogel kf...@newton.ch.collab.net.
Lele Gaifax lele@seldati.it writes:
Well, it seems that there is one more case. It happened right now to
me, and since I'm going to sleep, this is just to record the situation
here: the repos is very simple, and has been created a month ago, and
if needed I may eventually share it.
Actually, this is probably unrelated, because the checksum error you
got was due to checksum comparison code that has been in Subversion
since revision 1788 (Apr 2002), whose purpose is to verify the
integrity of .svn/text-base/foo.svn-base. It's entirely client-side
stuff.
There was a slight modification made to that code, because we migrated
from base64-encoded checksums to hex-encoded. That might have
something to do with the error. I'm quoting all of your recipe, to
make this easier for anyone to follow:
via http, with svn_dav 0.16.0. I was editing a new version of a
LyX document, that I wrongly created with its Save As option.
At this point, I did:
$ svn st
? AttoCostitutivo.lyx~
M PropostaStatutoSCR.lyx
? PropostaStatutoSCR.lyx~
? PropostaStatutoSCR.pdf
? PropostaStatutoSCR.ps
? PropostaStatutoSCR.txt
? StatutoSCR.lyx~
? StatutoSCR.pdf
? StatutoSCR.ps
? StatutoSCR_Compatto.lyx
? StatutoSCR_Compatto.ps
Uhm, I realized that I should have svn copied it instead, so I moved
it out of the way:
$ mv StatutoSCR_Compatto.lyx /tmp
$ svn cp StatutoSCR.lyx StatutoSCR_Compatto.lyx
$ svn st
? AttoCostitutivo.lyx~
M PropostaStatutoSCR.lyx
? PropostaStatutoSCR.lyx~
? PropostaStatutoSCR.pdf
? PropostaStatutoSCR.ps
? PropostaStatutoSCR.txt
? StatutoSCR.lyx~
? StatutoSCR.pdf
? StatutoSCR.ps
A + StatutoSCR_Compatto.lyx
? StatutoSCR_Compatto.ps
$ svn ci -m Copiato lo Statuto corrente per farne una versione
compatta StatutoSCR_Compatto.lyx
Adding StatutoSCR_Compatto.lyx
Committed revision 17.
$ cp /tmp/StatutoSCR_Compatto.lyx .
$ svn st
? AttoCostitutivo.lyx~
M PropostaStatutoSCR.lyx
? PropostaStatutoSCR.lyx~
? PropostaStatutoSCR.pdf
? PropostaStatutoSCR.ps
? PropostaStatutoSCR.txt
? StatutoSCR.lyx~
? StatutoSCR.pdf
? StatutoSCR.ps
M StatutoSCR_Compatto.lyx
? StatutoSCR_Compatto.ps
Okay. So far, everything looks good, no problems.
$ svn ci -m Reso su due colonne, eliminata la lista dei fondatori StatutoSCR_Compatto.lyx
Sending StatutoSCR_Compatto.lyx
Transmitting file data .svn: Working copy text base is corrupt
svn: Commit failed (details follow):
svn: svn_wc_transmit_text_deltas: checksum mismatch for '/home/lele/Scarambol/Documenti/.svn/text-base/StatutoSCR_Compatto.lyx.svn-base':
recorded checksum: f86e0240984a0240d81d0908a01d0908
actual checksum (hex): cb6161ca16f9984bd26b25a07c1f6b15
actual checksum (base64): y2Fhyhb5mEvSayWgfB9rFQ==
Okay, you must have been running a dev build somewhat past 0.16.1, or
you would have seen a different error text here. Furthermore, the
recorded checksum would have been in base64, since we didn't start
recording checksums in hex until after 0.16.1.
I freezed current repository (and I was surprised to find that a
tar.gz of it was 30Mb (!), starting from 46Mb, while a tar.bz2 was
just 14Mb (yes, less than half the gzipped one!)) for future
reference, and I'm building latest revision... and in a while I will
repeat the commit with newer client, then I will update the svn_dav
side of the matter... [... me lurking around waiting ...]
While waiting, I notice that the actual checksum matches that of the
text base version, while the record checksum comes from the entries
file for the working copy:
entry
committed-rev=17
name=StatutoSCR_Compatto.lyx
committed-date=2003-01-26T01:17:28.677353Z
checksum=f86e0240984a0240d81d0908a01d0908
last-author=lele
kind=file
revision=17/
Gotcha.
Ok, so now I have the latest client:
$ svn --version
svn, version 0.17.1 (dev build)
compiled Jan 26 2003, 02:55:40
and I repeat the last commit, that as I was supposing it emits the
very same message:
$ svn ci -m Reso su due colonne, eliminata la lista dei fondatori StatutoSCR_Compatto.lyx
Sending StatutoSCR_Compatto.lyx
Transmitting file data .svn: Working copy text base is corrupt
svn: Commit failed (details follow):
svn: svn_wc_transmit_text_deltas: checksum mismatch for '/home/lele/Scarambol/Documenti/.svn/text-base/StatutoSCR_Compatto.lyx.svn-base':
recorded checksum: f86e0240984a0240d81d0908a01d0908
actual checksum (hex): cb6161ca16f9984bd26b25a07c1f6b15
actual checksum (base64): y2Fhyhb5mEvSayWgfB9rFQ==
Okay, at least it's behaving consistently. Somehow the text base has
gotten corrupted, it seems. Are there any properties on this file?
Can you run 'svn pl -v StatutoSCR.lyx StatutoSCR_Compatto.lyx' and
post the output?
If you can narrow this down to a reproduction case involving just this
one file, and we can use that recipe with the exact same file, that
would be *great*.
Argh, the new client receives a plonk from the old dav, although an
svn st works:
$ svn cat http://caia:8888/svn/Scarambol/Documenti/StatutoSCR_Compatto.lyx /tmp/p.lyx
svn: RA layer request failed
svn: PROPFIND of /: Could not read status line: Connessione abbattuta dal corrispondente
Oops. Sorry about that. I'm not sure why it happened, but it's more
important to track down your (possible) text-base corruption right
now.
I'm tired, and will go on tomorrow on the server side. But as a last
try, I:
$ cd /tmp
$ mkdir p
$ cd p
$ svn co svn://caia/Scarambol .
...
Checked out revision 17.
$ cd p/Documenti
$ cp ~/Scarambol/Documenti/Statuto_SCR_Compatto.lyx .
$ svn st
M StatutoSCR_Compatto.lyx
$ svn ci -m Reso su due colonne, eliminata la lista dei fondatori StatutoSCR_Compatto.lyx
Sending StatutoSCR_Compatto.lyx
Transmitting file data .
Committed revision 18.
as expected, since svn doesn't use checksums.
svn doesn't use checksums == has no entries file to compare,
right?
A subsequent svn cat |
diff shows no differences ;-)
Ahh, okay, you can 'svn cat', so that probably means you downgraded
your client back to 0.16.1, right?
So what exactly was the diff command above? Without knowing what you
were comparing (working file? text base?), it doesn't mean much.
Thanks for the detailed report. With patience I hope we can work out
a reproduction recipe for this...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Karl Fogel kf...@newton.ch.collab.net.
Lele Gaifax lele@seldati.it writes:
Any news on this? I mean, is there anything I can do to help us
understanding what's going on? ...I'd expected at least a few words
after my after-hour :)
It was the weekend, that's all...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Lele Gaifax le...@seldati.it.
On Sun, 26 Jan 2003 03:31:19 +0100, Lele Gaifax lele@seldati.it said:
On 25 Jan 2003 11:33:51 -0600, Karl Fogel kfogel@newton.ch.collab.net said:
KF If you can come up with such a recipe, that would be a HUGE
KF help. You're one of the few people encountering this error
KF right now, so you're in a unique position to narrow this down
KF to a minimal, packageable recipe. Will you have time to do
KF that?
LG Well, it seems that there is one more case. It happened right
LG now to me, and since I'm going to sleep, this is just to
LG record the situation here: the repos is very simple, and has
LG been created a month ago, and if needed I may eventually share
LG it.
Any news on this? I mean, is there anything I can do to help us
understanding what's going on? ...I'd expected at least a few words
after my after-hour :)
thanxbye,
lele.
--
nickname: Lele Gaifax | Quando vivr� di quello che ho pensato ieri
real: Emanuele Gaifas | comincer� ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Lele Gaifax le...@seldati.it.
On 25 Jan 2003 11:33:51 -0600, Karl Fogel kfogel@newton.ch.collab.net said:
KF So far, we've had a couple of reports of checksum mismatches,
KF all from that same place in apply_window(). None of them have
KF been reproducible, in the sense of a recipe that a) anyone can
KF run, and b) reproduces the problem every time.
KF If you can come up with such a recipe, that would be a HUGE
KF help. You're one of the few people encountering this error
KF right now, so you're in a unique position to narrow this down
KF to a minimal, packageable recipe. Will you have time to do
KF that?
Well, it seems that there is one more case. It happened right now to
me, and since I'm going to sleep, this is just to record the situation
here: the repos is very simple, and has been created a month ago, and
if needed I may eventually share it.
I was accessing it with
$ svn --version
svn, version 0.16.1 (dev build)
compiled Jan 15 2003, 00:39:36
via http, with svn_dav 0.16.0. I was editing a new version of a
LyX document, that I wrongly created with its Save As option.
At this point, I did:
$ svn st
? AttoCostitutivo.lyx~
M PropostaStatutoSCR.lyx
? PropostaStatutoSCR.lyx~
? PropostaStatutoSCR.pdf
? PropostaStatutoSCR.ps
? PropostaStatutoSCR.txt
? StatutoSCR.lyx~
? StatutoSCR.pdf
? StatutoSCR.ps
? StatutoSCR_Compatto.lyx
? StatutoSCR_Compatto.ps
Uhm, I realized that I should have svn copied it instead, so I moved
it out of the way:
$ mv StatutoSCR_Compatto.lyx /tmp
$ svn cp StatutoSCR.lyx StatutoSCR_Compatto.lyx
$ svn st
? AttoCostitutivo.lyx~
M PropostaStatutoSCR.lyx
? PropostaStatutoSCR.lyx~
? PropostaStatutoSCR.pdf
? PropostaStatutoSCR.ps
? PropostaStatutoSCR.txt
? StatutoSCR.lyx~
? StatutoSCR.pdf
? StatutoSCR.ps
A + StatutoSCR_Compatto.lyx
? StatutoSCR_Compatto.ps
$ svn ci -m Copiato lo Statuto corrente per farne una versione
compatta StatutoSCR_Compatto.lyx
Adding StatutoSCR_Compatto.lyx
Committed revision 17.
$ cp /tmp/StatutoSCR_Compatto.lyx .
$ svn st
? AttoCostitutivo.lyx~
M PropostaStatutoSCR.lyx
? PropostaStatutoSCR.lyx~
? PropostaStatutoSCR.pdf
? PropostaStatutoSCR.ps
? PropostaStatutoSCR.txt
? StatutoSCR.lyx~
? StatutoSCR.pdf
? StatutoSCR.ps
M StatutoSCR_Compatto.lyx
? StatutoSCR_Compatto.ps
$ svn ci -m Reso su due colonne, eliminata la lista dei fondatori StatutoSCR_Compatto.lyx
Sending StatutoSCR_Compatto.lyx
Transmitting file data .svn: Working copy text base is corrupt
svn: Commit failed (details follow):
svn: svn_wc_transmit_text_deltas: checksum mismatch for '/home/lele/Scarambol/Documenti/.svn/text-base/StatutoSCR_Compatto.lyx.svn-base':
recorded checksum: f86e0240984a0240d81d0908a01d0908
actual checksum (hex): cb6161ca16f9984bd26b25a07c1f6b15
actual checksum (base64): y2Fhyhb5mEvSayWgfB9rFQ==
I freezed current repository (and I was surprised to find that a
tar.gz of it was 30Mb (!), starting from 46Mb, while a tar.bz2 was
just 14Mb (yes, less than half the gzipped one!)) for future
reference, and I'm building latest revision... and in a while I will
repeat the commit with newer client, then I will update the svn_dav
side of the matter... [... me lurking around waiting ...]
While waiting, I notice that the actual checksum matches that of the
text base version, while the record checksum comes from the entries
file for the working copy:
entry
committed-rev=17
name=StatutoSCR_Compatto.lyx
committed-date=2003-01-26T01:17:28.677353Z
checksum=f86e0240984a0240d81d0908a01d0908
last-author=lele
kind=file
revision=17/
Ok, so now I have the latest client:
$ svn --version
svn, version 0.17.1 (dev build)
compiled Jan 26 2003, 02:55:40
and I repeat the last commit, that as I was supposing it emits the
very same message:
$ svn ci -m Reso su due colonne, eliminata la lista dei fondatori StatutoSCR_Compatto.lyx
Sending StatutoSCR_Compatto.lyx
Transmitting file data .svn: Working copy text base is corrupt
svn: Commit failed (details follow):
svn: svn_wc_transmit_text_deltas: checksum mismatch for '/home/lele/Scarambol/Documenti/.svn/text-base/StatutoSCR_Compatto.lyx.svn-base':
recorded checksum: f86e0240984a0240d81d0908a01d0908
actual checksum (hex): cb6161ca16f9984bd26b25a07c1f6b15
actual checksum (base64): y2Fhyhb5mEvSayWgfB9rFQ==
Argh, the new client receives a plonk from the old dav, although an
svn st works:
$ svn cat http://caia:8888/svn/Scarambol/Documenti/StatutoSCR_Compatto.lyx /tmp/p.lyx
svn: RA layer request failed
svn: PROPFIND of /: Could not read status line: Connessione abbattuta dal corrispondente
I'm tired, and will go on tomorrow on the server side. But as a last
try, I:
$ cd /tmp
$ mkdir p
$ cd p
$ svn co svn://caia/Scarambol .
...
Checked out revision 17.
$ cd p/Documenti
$ cp ~/Scarambol/Documenti/Statuto_SCR_Compatto.lyx .
$ svn st
M StatutoSCR_Compatto.lyx
$ svn ci -m Reso su due colonne, eliminata la lista dei fondatori StatutoSCR_Compatto.lyx
Sending StatutoSCR_Compatto.lyx
Transmitting file data .
Committed revision 18.
as expected, since svn doesn't use checksums. A subsequent svn cat |
diff shows no differences ;-)
my bed is going away if I do not reach it in a minute, but most of you
are just awakening, so if anyone, after the needed caffeine or
surrogate, suggests a test or something, I will try to do my best
tomorrow |-)
ciao, lele.
--
nickname: Lele Gaifax | Quando vivr� di quello che ho pensato ieri
real: Emanuele Gaifas | comincer� ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Dominik Westner li...@logicunited.com.
well, I had some of this checksumming errors, too.
In my case it was (I think) some sort of version mismatch on different
clients and the server.
It did not occur to me after upgrading everything to 17.1. and dumping
and loading the repository.
Dominik
On Saturday, January 25, 2003, at 06:33 PM, Karl Fogel wrote:
solo turn soloturn99@yahoo.com writes:
there must be some automatic action to resolve this, i would suggest
recalculate it for a month or so (if the cause is old rep.). what
does an end-user care about checksums?
must be? Any checksum mismatch indicates that something has gone
wrong. Let's concentrate on finding out what it was, not on adding
enhancements to Subversion :-).
So far, we've had a couple of reports of checksum mismatches, all from
that same place in apply_window(). None of them have been
reproducible, in the sense of a recipe that a) anyone can run, and b)
reproduces the problem every time.
If you can come up with such a recipe, that would be a HUGE help.
You're one of the few people encountering this error right now, so
you're in a unique position to narrow this down to a minimal,
packageable recipe. Will you have time to do that?
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Karl Fogel kf...@newton.ch.collab.net.
solo turn soloturn99@yahoo.com writes:
there must be some automatic action to resolve this, i would suggest
recalculate it for a month or so (if the cause is old rep.). what
does an end-user care about checksums?
must be? Any checksum mismatch indicates that something has gone
wrong. Let's concentrate on finding out what it was, not on adding
enhancements to Subversion :-).
So far, we've had a couple of reports of checksum mismatches, all from
that same place in apply_window(). None of them have been
reproducible, in the sense of a recipe that a) anyone can run, and b)
reproduces the problem every time.
If you can come up with such a recipe, that would be a HUGE help.
You're one of the few people encountering this error right now, so
you're in a unique position to narrow this down to a minimal,
packageable recipe. Will you have time to do that?
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by solo turn so...@yahoo.com.
--- Justin Erenkrantz jerenkrantz@apache.org wrote:
--On Saturday, January 25, 2003 7:58 AM -0800 solo turn
soloturn99@yahoo.com wrote:
it seems that checksumming is ill:
...
svn: A checksum mismatch occurred
svn: apply_window: checksum mismatch after applying text delta
(b1/bb/bbc/.svn/tmp/text-base/bbba.txt.svn-base):
expected checksum: 34f9383e157bc6305f4c7e2290d6ac39
actual checksum: d41d8cd98f00b204e9800998ecf8427e
what is your ra layer?
http
the checksum as denoted in the text-base correct or incorrect? Was
$ ls -l b1/bb/bbc/.svn/tmp/text-base/bbba.txt.svn-base
b1/bb/bbc/.svn/tmp/text-base/bbba.txt.svn-base: No such file or
directory
the actual checksum is the one of the file in the repository, resp.
on the disk. so i guess the expected checksum is wrong.
the repository new or old? (There was a bit of time when the
existing repository, therefor the create part is missing. the file
itself was created in 2002/08 and not changed afterwards, current svn
version at that time.
checksum code was wrong - perhaps you are seeing this?) Have you
tried to dump/load the repository?
no.
generally i'm VERY concerned about the .svn folder. it is a
system
directory, and it is never the master. it has to be treated like
that (i.e. fixed automatically).
Huh? This paragraph doesn't parse at all. -- justin
there must be some automatic action to resolve this, i would suggest
recalculate it for a month or so (if the cause is old rep.). what
does an end-user care about checksums?
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: checksumming crap
Posted by Justin Erenkrantz je...@apache.org.
--On Saturday, January 25, 2003 7:58 AM -0800 solo turn
soloturn99@yahoo.com wrote:
it seems that checksumming is ill:
...
svn: A checksum mismatch occurred
svn: apply_window: checksum mismatch after applying text delta
(b1/bb/bbc/.svn/tmp/text-base/bbba.txt.svn-base):
expected checksum: 34f9383e157bc6305f4c7e2290d6ac39
actual checksum: d41d8cd98f00b204e9800998ecf8427e
We have had no verifiable reports of where the checksum code was at
fault.
As usual, you are omitting key details: what is your ra layer? Is
the checksum as denoted in the text-base correct or incorrect? Was
the repository new or old? (There was a bit of time when the
checksum code was wrong - perhaps you are seeing this?) Have you
tried to dump/load the repository?
I just tried to reproduce something similar to your incomplete
reproduction case with ra_local and it worked fine.
generally i'm VERY concerned about the .svn folder. it is a system
directory, and it is never the master. it has to be treated like
that (i.e. fixed automatically).
Huh? This paragraph doesn't parse at all. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org