git-svn problem with v1.6.5
Hello,
A git-svn mirror is created using Git v1.6.4. When I copy this mirror into another machine which is using v1.6.5 I get the following error:
$ git svn rebase fatal: Invalid revision range d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk rev-list --pretty=raw --no-color --reverse d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk --: command returned error: 128
Using v1.6.4 instead I have no problem. Any idea to track this problem down?
Thanks.
Pascal.
Signature · 8 lines
--|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
Quoted 6 lines · Pascal Obry
$ git svn rebase fatal: Invalid revision range d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk rev-list --pretty=raw --no-color --reverse d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk --: command returned error: 128
Is d2cf08bb67e4b7da33a250127aab784f1f2f58d3 a valid revision? (git log d2cf08bb67e4b7da33a250127aab784f1f2f58d3). Is refs/remotes/svn/trunk valid? (git log refs/remotes/svn/trunk). It seems like a strange problem.
Quoted 1 line
Using v1.6.4 instead I have no problem. Any idea to track this problem down?
You could try using git bisect to figure out which exact commit to git.git created the problem.
Avery
Avery,
Quoted 2 lines
Is
d2cf08bb67e4b7da33a250127aab784f1f2f58d3a valid revision? (git logd2cf08bb67e4b7da33a250127aab784f1f2f58d3).
No.
Quoted 1 line
Is refs/remotes/svn/trunk valid? (git log refs/remotes/svn/trunk).
Yes.
Quoted 1 line
It seems like a strange problem.
Agreed!
Quoted 2 lines
You could try using git bisect to figure out which exact commit to git.git created the problem.
I wanted to avoid that :) Anyway, here is the culprit:
commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d
Author: Adam Brewster <[email protected]> Date: Tue Aug 11 23:14:27 2009 -0400
svn: allow branches outside of refs/remotes
It may be convenient for some users to store svn remote tracking branches outside of the refs/remotes/ heirarchy.
To accomplish this feat, this patch includes the entire path to the ref in $r->{'refname'} in &read_all_remotes and tries to change references to this entry so the new value makes sense.
[ew: fixed backwards compatibility, long lines]
git-svn.perl | 83 ++++++++++++++++++++++---------------- t/lib-git-svn.sh | 2 +- t/t9104-git-svn-follow-parent.sh | 10 ++-- t/t9107-git-svn-migrate.sh | 14 +++---- t/t9143-git-svn-gc.sh | 10 ++-- t/t9144-git-svn-old-rev_map.sh | 31 ++++++++++++++ 6 files changed, 96 insertions(+), 54 deletions(-)
But frankly I'm no expert on Perl... I fear that I won't be able to debug that!
Pascal.
Signature · 8 lines
--|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
Quoted 5 lines · Pascal Obry
Quoted 3 lines
Avery wrote:
Isd2cf08bb67e4b7da33a250127aab784f1f2f58d3a valid revision? (git logd2cf08bb67e4b7da33a250127aab784f1f2f58d3).No.
Well, that's bad news. Does "git log --all --parents | grep d2cf08bb67e4b7da33a250127aab784f1f2f58d3" reveal any places that refer to it?
It sounds a bit like your git-svn thinks something maps on to that commit id, but a previous 'git gc' or something has thrown it away. However, that doesn't explain why earlier git versions don't have this problem.
Quoted 10 lines
Quoted 2 lines
You could try using git bisect to figure out which exact commit to git.git created the problem.
I wanted to avoid that :) Anyway, here is the culprit:
commit
6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d
Author: Adam Brewster <[email protected]>
Date: Tue Aug 11 23:14:27 2009 -0400svn: allow branches outside of refs/remotes
[...]
Quoted 3 lines
But frankly I'm no expert on Perl... I fear that I won't be able to debug that!
If you retrieve the latest version of git and then git revert the above commit, does that fix the problem, at least?
Is it possible you have some weird branches outside of the refs/remotes tree (either in .git itself, or in .git/refs/*) that you forgot about, and which the new version of git-svn is finding somehow?
Avery
Avery,
Quoted 3 lines
Well, that's bad news. Does "git log --all --parents | grep
d2cf08bb67e4b7da33a250127aab784f1f2f58d3" reveal any places that refer to it?
No.
Quoted 4 lines
It sounds a bit like your git-svn thinks something maps on to that commit id, but a previous 'git gc' or something has thrown it away. However, that doesn't explain why earlier git versions don't have this problem.
Maybe, but that would be a quite annoying bug!
Quoted 2 lines
If you retrieve the latest version of git and then git revert the above commit, does that fix the problem, at least?
I cannot, this does not revert cleanly and I don't know how to properly resolve this conflict. I'm no Perl expert!
But reverting using the version just before fixes this problem.
Quoted 3 lines
Is it possible you have some weird branches outside of the refs/remotes tree (either in .git itself, or in .git/refs/*) that you forgot about, and which the new version of git-svn is finding somehow?
I do not see something under .git/refs/* (only empty directories).
The project has been imported using something like this:
$ git svn clone --prefix=svn/ svn+ssh://server/path \ --revision=580:HEAD \ --trunk=trunk/project \ --tags=tags/project \ --branches=branches/project \ --branches="branches/global/*/project" project
Nothing fancy. The git-svn mirrors is updated every night using Git 1.6.4 without problem.
Pascal.
Signature · 8 lines
--|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
Quoted 7 lines · Pascal Obry
Avery,
Quoted 3 lines
Well, that's bad news. Does "git log --all --parents | grep
d2cf08bb67e4b7da33a250127aab784f1f2f58d3" reveal any places that refer to it?No.
Weird...
Quoted 7 lines
Quoted 4 lines
It sounds a bit like your git-svn thinks something maps on to that commit id, but a previous 'git gc' or something has thrown it away. However, that doesn't explain why earlier git versions don't have this problem.
Maybe, but that would be a quite annoying bug!
Quoted 7 lines
Quoted 2 lines
If you retrieve the latest version of git and then git revert the above commit, does that fix the problem, at least?
I cannot, this does not revert cleanly and I don't know how to properly resolve this conflict. I'm no Perl expert!
But reverting using the version just before fixes this problem.
That should rule out filesystem corruption...
Quoted 6 lines
Quoted 3 lines
Is it possible you have some weird branches outside of the refs/remotes tree (either in .git itself, or in .git/refs/*) that you forgot about, and which the new version of git-svn is finding somehow?
I do not see something under .git/refs/* (only empty directories).
Quoted 8 lines
The project has been imported using something like this:
$ git svn clone --prefix=svn/ svn+ssh://server/path \ --revision=580:HEAD \ --trunk=trunk/project \ --tags=tags/project \ --branches=branches/project \ --branches="branches/global/*/project" project
It looks like you didn't use any of the weird[1] options that make it unsafe to clobber the rev_maps. Can you try removing all the .rev_map.* files in $GIT_DIR/svn and running "git svn fetch" to rebuild them?
[1] --no-metadata, --use-svm-props
Signature · 1 line
Eric Wong
Quoted 12 lines · Eric Wong
Quoted 10 lines · Pascal Obry
I do not see something under .git/refs/* (only empty directories).
The project has been imported using something like this:
$ git svn clone --prefix=svn/ svn+ssh://server/path \ --revision=580:HEAD \ --trunk=trunk/project \ --tags=tags/project \ --branches=branches/project \ --branches="branches/global/*/project" project
Quoted 5 lines
It looks like you didn't use any of the weird[1] options that make it unsafe to clobber the
rev_maps. Can you try removing all the .rev_map.* files in $GIT_DIR/svn and running "git svn fetch" to rebuild them?[1] --no-metadata, --use-svm-props
Also, any chance you have multiple refs with "trunk" in the basename?
git rev-parse --symbolic --all | grep '/trunk'
It could be a backwards compatibility issue with git svn looking in multiple places for trunk.
With Adam's commit, it'll try $GIT_DIR/svn/refs/remotes/trunk/* first Then it'll try $GIT_DIR/svn/trunk/* as a fallback.
Signature · 1 line
Eric Wong
Eric,
Quoted 3 lines
Also, any chance you have multiple refs with "trunk" in the basename?
git rev-parse --symbolic --all | grep '/trunk'
This reports:
$ git rev-parse --symbolic --all | grep '/trunk' refs/remotes/svn/trunk
Quoted 2 lines
It could be a backwards compatibility issue with git svn looking in multiple places for trunk.
But I have multiple trunk:
$ ls .git/svn/svn/trunk/ ./ ../ .rev_map.936e1b1b-40f2-da11-902a-00137254ae57 unhandled.log
$ ls .git/svn/refs/remotes/svn/trunk/ ./ ../ .rev_map.936e1b1b-40f2-da11-902a-00137254ae57 unhandled.log
Removing all the .rev_map* fix the problem.
Removing only the one in .git/svn/refs/remotes/svn/trunk/ fix the problem too.
Quoted 2 lines
With Adam's commit, it'll try $GIT_DIR/svn/refs/remotes/trunk/* first Then it'll try $GIT_DIR/svn/trunk/* as a fallback.
Does this means that it was looking first in $GIT_DIR/svn/trunk/* before? And the confusion come because now it is looking in $GIT_DIR/svn/refs/remotes/trunk/* first?
Pascal.
Signature · 8 lines
--|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
Quoted 10 lines · Pascal Obry
Eric,
Quoted 3 lines
Also, any chance you have multiple refs with "trunk" in the basename?
git rev-parse --symbolic --all | grep '/trunk'This reports:
$ git rev-parse --symbolic --all | grep '/trunk' refs/remotes/svn/trunk
Pascal,
OK, this is normal.
Quoted 16 lines
Quoted 2 lines
It could be a backwards compatibility issue with git svn looking in multiple places for trunk.
But I have multiple trunk:
$ ls .git/svn/svn/trunk/ ./ ../ .rev_map.936e1b1b-40f2-da11-902a-00137254ae57 unhandled.log$ ls .git/svn/refs/remotes/svn/trunk/ ./ ../ .rev_map.936e1b1b-40f2-da11-902a-00137254ae57 unhandled.logRemoving all the .rev_map* fix the problem.
Removing only the one in .git/svn/refs/remotes/svn/trunk/ fix the problem too.
Quoted 6 lines
Quoted 2 lines
With Adam's commit, it'll try $GIT_DIR/svn/refs/remotes/trunk/* first Then it'll try $GIT_DIR/svn/trunk/* as a fallback.
Does this means that it was looking first in $GIT_DIR/svn/trunk/* before? And the confusion come because now it is looking in $GIT_DIR/svn/refs/remotes/trunk/* first?
Yes, but somehow $GIT_DIR/svn/refs/remotes/trunk should not have been created since $GIT_DIR/svn/svn/trunk already existed. Both of those directories existing at the same time should not
Did you try an early version of Adam's patch before it made it into git.git by any chance?
Or, did you by any chance start a fresh import with a v1.6.5 and then rsync $GIT_DIR to one created with 1.6.4 and not use --delete with rsync?
Signature · 1 line
Eric Wong
Eric,
Quoted 2 lines
Did you try an early version of Adam's patch before it made it into git.git by any chance?
No.
Quoted 3 lines
Or, did you by any chance start a fresh import with a v1.6.5 and then rsync $GIT_DIR to one created with 1.6.4 and not use --delete with rsync?
No. The import has been done with 1.6.4. A filter-branch has been applied to fix author names. But AFAIK (will check) it has been done with 1.6.4 too.
Pascal.
Signature · 8 lines
--|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
Quoted 7 lines · Pascal Obry
Eric,
Quoted 2 lines
Did you try an early version of Adam's patch before it made it into git.git by any chance?
No.
Quoted 7 lines
Quoted 3 lines
Or, did you by any chance start a fresh import with a v1.6.5 and then rsync $GIT_DIR to one created with 1.6.4 and not use --delete with rsync?
No. The import has been done with 1.6.4. A filter-branch has been applied to fix author names. But AFAIK (will check) it has been done with 1.6.4 too.
Oh... Any chance that lost commit you couldn't find was clobbered by filter-branch? That would explain a lot...
Signature · 1 line
Eric Wong
Eric,
Quoted 2 lines
Oh... Any chance that lost commit you couldn't find was clobbered by filter-branch? That would explain a lot...
I still have the AWS repo as it was from initial import. And I can see the commit
on this one:
$ git log --all --parents | grep d2cf08bb67e4b7da33a250127aab784f1f2f58d3 commit bd95b2b254286e6f04015b7f58266d66abc134a7 d2cf08bb67e4b7da33a250127aab784f1f2f58d3 commit d2cf08bb67e4b7da33a250127aab784f1f2f58d3 406eaf7e51229f60048ea80cdb6904e33ef59a81
So that's definitely a problem with the filter-branch. Thanks a lot for your precious help!
Will review the procedure for filtering branches :(
Pascal.
Signature · 8 lines
--|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Eric,
Quoted 1 line
Will review the procedure for filtering branches :(
A quick review does not show something obviously wrong on my side.
The commit on the rewritten repo has a different sha-1 which is expected. So to me it seems that after a filter-branch on a git-svn repo it is mandatory to recreate all .rev_map*? Is that right? Is so, this is the missing piece in the procedure on my side.
Pascal.
Signature · 8 lines
--|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Quoted 10 lines · Pascal Obry
Eric,
Quoted 1 line
Will review the procedure for filtering branches :(
A quick review does not show something obviously wrong on my side.
The commit on the rewritten repo has a different sha-1 which is expected. So to me it seems that after a filter-branch on a git-svn repo it is mandatory to recreate all .rev_map*? Is that right? Is so, this is the missing piece in the procedure on my side.
Yes, you need to recreate all the .rev_map* files if you use filter-branch. Just remove them and they should be automatically recreated for your case (not using --no-metadata or --use-svm-props)
Signature · 1 line
Eric Wong
Eric,
Quoted 3 lines
Yes, you need to recreate all the .rev_map* files if you use filter-branch. Just remove them and they should be automatically recreated for your case (not using --no-metadata or --use-svm-props)
Thanks for the confirmation, I'll do that.
Pascal.
Signature · 8 lines
--|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Quoted 5 lines · Pascal Obry
Hello,
A git-svn mirror is created using Git v1.6.4. When I copy this mirror into another machine which is using v1.6.5 I get the following error:
Quoted 9 lines
$ git svn rebase fatal: Invalid revision range d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk rev-list --pretty=raw --no-color --reverse d2cf08bb67e4b7da33a250127aab784f1f2f58d3..refs/remotes/svn/trunk --: command returned error: 128Using v1.6.4 instead I have no problem. Any idea to track this problem down?
Did you copy the entire directory across using rsync/tar/etc or 'git
clone' ? You'll need to make sure that the 'refs/remotes/*' refs look
exactly the same on the clone as they did on the original import repository.
Sam
Sam,
Quoted 2 lines
Did you copy the entire directory across using rsync/tar/etc or 'git clone' ?
I did a rsync of the .git directory so I expect all refs to be there.
Pascal.
Signature · 8 lines
--|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B