48

I have a problem when I try to do a git svn rebase on my repository. It displays :

Checksum mismatch: code/app/meta_appli/app_info.py
expected: d9cefed5d1a630273aa3742f7f414c83
     got: 4eb5f3506698bdcb64347b5237ada19f

I searched a lot but haven't found a way to solve this problem.

If anybody knows, please share your knowledge. Thanks in advance.

Amandasaurus
  • 58,203
  • 71
  • 188
  • 248
darkpotpot
  • 1,321
  • 2
  • 11
  • 25
  • 1
    This looks to be similar to your problem: http://kerneltrap.org/mailarchive/git/2010/2/18/23715 – NorthGuard Jul 01 '10 at 17:30
  • 2
    yeah, thanks for the link. For the record I managed to make it works again by removing the file from the svn server, doing a checkout to the latest revision and then adding the file again on svn. It's pretty harsh but I didn't found another way. – darkpotpot Jul 07 '10 at 08:54

6 Answers6

68

This solution was the only one that worked for me:

See what was the revision number of the last change on the file:

git svn log chrome/test/functional/search_engines.py

Reset svn to be closest parent before that revision:

git svn reset -r62248 -p

Do a git svn fetch!

Dance at your success.

Domenic
  • 110,262
  • 41
  • 219
  • 271
  • 4
    Great find. This is definitely the way to do it, from what I've seen. The git svn log step was crucial, although I needed to use it as follows: git svn log -- chrome/test/functional/search_engines.py. Note the -- which indicates a path to a file follows, in this case. – Matt D May 08 '12 at 04:13
  • 2
    A special case that requires more work: the subversion repo had a `svn:special=*` attributed file (symlink) that was accidentally replaced by target file. This caused "file name too long" errors with `git-svn`, and then after fixing the file in subversion we got `checksum mismatch` errors with `git-svn`. Full solution here was: 1) `git svn rebase --ignore-paths=`; 2) set `core.symlinks = false` in `.git/config`; 3) do the `git svn reset` you describe above; 4) do `git svn rebase`; 5) remove the `core.symlinks = false` from `.git/config`. Ouch! – ntc2 May 30 '12 at 21:13
  • 4
    Additionally worth mentioning, this has come up one or two other times, and after doing the git svn reset, a git gc ensures the "stranded" history is cleaned up and not recycled. (which can cause the issue to repeat itself) You may not have to do this, but it helped in my case. – Matt D Jun 22 '12 at 03:57
  • 5
    In response to git svn log -- path/file I get `fatal: bad default revision 'HEAD'`. This is the first fetch so I have no working copy. Any ideas please? – Chris Jul 18 '14 at 07:45
  • @ntc2 you sir deserve an ice cold beer! – foxx1337 Jun 29 '15 at 09:58
  • 1
    Nice! But why does the checksum mismatch happen? – xi.lin Sep 21 '15 at 13:51
  • 2
    `git svn log trunk/file.x` only shows a line to me `------------` – Daniel W. Jan 18 '16 at 10:06
  • @xi.lin I have seen a number of ways `git svn` can produce a bad history. The most common examples have seen involve merges, when you find that 1 of many otherwise-always-equal git-svn clones jumps out of agreement. One problem is that it can choose different parent-commits for the merge, and another is it can lose or corrupt a file in the merge in git. – javabrett May 12 '16 at 03:10
  • @xi.lin - the SVN and Git repos get out of sync. When Git built the previous rev from svn it botched it and so now the file that SVN is expecting to be the predecessor does not match what Git has as the predecessor and it's impossible to apply the patch without corruption. This is why Git-Svn throws an error and asks you to rebuild the git revs so they match SVN again. – AJ Henderson Dec 12 '17 at 15:10
  • @Domenic - you should probably add MattD's comment to the answer. There are some cases (like the one I just had) where doing a reset, even to several versions prior and then fetching will still result in an error due to the cached revisions. It led to a very confusing situation where Git-SVN successfully worked on the file multiple times before getting the error at the same place as before. – AJ Henderson Dec 12 '17 at 15:12
  • Note (Daniel W.) that the reset only works after having checked out the branch. And that you reset only this branch. If you want to reset *everything* after a given revision, you can grep to find all affected branches, then reset. e.g. let's say that 292813 crashed due to No space left on device, but git svn continued until 292844 (although doing empty commits, so resulting in a checksum mismatch after recovering space), let's restart at 292810: ( cd .git/logs/refs && egrep -rl 'r(2928[1-4][0-9])$' remotes/origin ) | while read b ; do git checkout "$b" && git svn reset -r 292810 ; done – Guillaume Outters Nov 06 '19 at 13:51
2

I encountered this error when I just specified branches but no trunk. When I specified one of the branches as trunk, there was no error any more when I retried. (The whole "trunk", "branch", "trunk" distinction is generally speaking a bit silly to enforce in git svn as they are just human conventions without any deeper technical meaning behind them in svn.)

FooF
  • 4,323
  • 2
  • 31
  • 47
1

Just happened to me, I run out of space in the middle of a "git svn dcommit" and after that I was getting the same message, "Checksum mismatch".

I just edited .git/refs/remotes/git-svn and replaced the id of the problematic commit with the previous one. Next rebase fixes the problem.

ollupac
  • 11
  • 1
0

I just did a git gc and then git svn rebase worked again.

unhammer
  • 4,306
  • 2
  • 39
  • 52
0

In our practice the error "Checksum mismatch:" on .shtml files in git svn clone ... command was caused by the setup of the front-end Apache server to interpret the.shtml files (from SVN) as Server-Side Includes (SSI) and thus produce live content instead of just providing the stored file content. Disabling SSI in Apache's /etc/httpd.conf file for the period of migration by commenting out the

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

directives solved the problem.
Anyway, the migration of the repository could exclude some paths and files happens with:

git svn clone <URL> --ignore-paths=<regex>

clause. It makes sense to check the environment of the SVN server process if those files have special interpretation like SSI (and the .php and .py files) and disable it.

Mr Lister
  • 45,515
  • 15
  • 108
  • 150
Rusi Popov
  • 377
  • 1
  • 6
0

Additionnally to Domenic's answer (still svn-to-gitting in 2019…):

In the specific case of a deleted-then-recreated branch (1), reset should be applied to the branch creation commit, after having deleted references to the old branch:

> git svn fetch
…
r146970 = …
Checksum mismatch: bla.x # Uh oh, there we go!
> # Seems to have occurred while fetching r146971 (last passed rev + 1), so let's try it:
> svn log -v -r 146971 $svn
M /branches/y/bla.x
> # OK, bla.x is a good indicator that this is indeed our failing commit.
> # What was the preceding commit on it, according to SVN?
> svn log -v -r 146971 $svn/branches/y/bla.x | less
------------------------------------------------------------------------
r146971
  M /branches/y/bla.x
Modified bla.x
------------------------------------------------------------------------
r145665
  A /branches/y (from /branches/z:145664)
Rebasing y on z
------------------------------------------------------------------------
> # Exactly what we were looking for: a branch creation. Let us clean branch y
> # so that git-svn is forced to find its recreation commit:
> rm -R .git/refs/remotes/origin/y .git/*/refs/remotes/origin/y
> vi .git/info/refs .git/packed-refs # remove references to y
> git svn reset -r145665 -p
> git svn fetch

I'm supposing that git-svn did not see or apply the branch deletion, thought it was unnecessary to recreate it from branch z, and thus tried to applied 146971 on the old tree. Telling it there is no branch y forces it to play the branch creation (from z).

(1) mimicking in svn the equivalent of a git rebase z of branch y: svn mv y y.old && svn cp z y && svn merges to get all commits of y.old on the new y

Guillaume Outters
  • 310
  • 2
  • 8