Error using git-svn on existing repository #233
Labels
Comments
|
Ok, I deleted |
|
Thanks for the analysis. It seems to be safe to delete .git/svn/.caches, after all it is just a cache and can be reconstructed. I wonder what we can do about this, though. Maybe it is possible to catch that error in git-svn, line 49, and simply remove the caches if a byte order change was detected? |
|
This has to do with the switch from 32bit to 64bit. You have to clear the caches every time you want to use a different bitness. |
|
Oh yes, of course, it is not really bit order but word size... Thanks for pointing that out! |
|
Seems the code in Please note that this is probably only a problem if the Storable backend is used, not the YAML one. So maybe there is an easy way to detect with something like if (-e "$path.db") {
eval { retrieve("$path.db") }
unlink "$path.db" unless ($@);
}NOTE: this is just a sketch of a solution, @uecasm feel free to play with this, as I seem to be unable to find a Subversion repository with which that |
|
Sorry for the delay. I'm a bit wary of breaking my repo again since it has some important code in it and I wanted to get it safely committed first. But I tried putting back the old caches folder from v1.9.5 (without applying the suggested fix) and I couldn't reproduce the problem with a I may need to try again later when the SVN repo has had a few more third party commits or something. In case it helps discover what might trigger use of the files, the ones that I have from Git 1 are:
And the ones that were recreated by Git 2 (after I had removed the files the first time) were:
Since the original error was talking about (Unfortunately I can't make an MCVE because part of what triggered the migration to GfW 2 in the first place was that the rebase bug is stopping me from running GfW 1 any more.) |
|
Thanks for coming back. However, I think a bit more from your side will be needed than what you described to be your plan. Please note that it is quite possible with Subversion to initialize your own Subversion repository in a plain old directory! That way, you can experiment with all the operations you suspect are related to this issue, and even better: you can then .zip up the Subversion repository and make an MCVE out of it. Bonus: no meddling with your production system, and neither do you have to frustrate developers willing to help you by stating that they cannot have your repository because there are trade secrets in it. Note: This is no longer a promise that I will help, but I feel that there is just no chance to motivate anybody else to jump in if they are asked to do all the experimenting themselves. |
|
I know I can make a local repository. As I said, that's not the problem. The problem is that reproducing the bug requires either that I use the cache files from my existing working copy that previously demonstrated the bug (which requires things to happen in that repository that will probably take a day or two), or that I make a new repo and reproduce the problem -- but the latter would require GfW 1.9 to actually work on my PC (since that's a precondition of the bug, to generate the old-format cache files in the first place), and it simply doesn't. There's not much that I can do about that (rebasing doesn't work). So it's either the waiting game, or see if someone else can reproduce it in the meantime. |
|
Ok, someone merged something in SVN, so There was a syntax error in the suggested fix, so I had to fiddle with the code a bit, but I eventually got something that appears to work. I'll submit a PR for the specific change in a moment. |
uecasm
added a commit
to uecasm/git
that referenced
this issue
Jul 17, 2015
dscho
added a commit
that referenced
this issue
Jul 18, 2015
As per #246 (comment) replace the commit message by: git-svn: do not reuse caches memoized for a different architecture Reusing cached data speeds up git-svn by quite a fair bit. However, if the YAML module is unavailable, the caches are written to disk in an architecture-dependent manner. That leads to problems when upgrading, say, from 32-bit to 64-bit Git for Windows. Let's just try to read those caches back if we detect the absence of the YAML module and the presence of the file, and delete the file if it could not be read back correctly. Note that the only way to catch the error when the memoized cache could not be read back is to put the call inside an `eval { ... }` block because it would die otherwise; the `eval` block should also return `1` in case of success explicitly since the function reading back the cached data does not return an appropriate value to test for success. This fixes #233. [jes: fixed the commit message, made the sign-off explicit] Signed-off-by: Gavin Lambert <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Jul 18, 2015
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes git-for-windows#233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
|
Per your prior comment suggesting that the YAML backend might not be vulnerable to this issue (and thus might be an alternate [more robust?] fix, I looked briefly at the code trying to work out why it would pick one over the other. It appears that SVN.pm will use YAML whenever it can successfully require YAML.pm. Given that the YAML module appears to be distributed in GfW (C:\Program Files\git\mingw64\share\perl5\site_perl\Git\SVN\Memoize\YAML.pm), it's presumably the dependency on a global YAML module within this file that's causing it to fail. Could this just be a dependency that needs to be added to the Perl distribution within GfW? Or is this not available from upstream? |
|
Frankly, I have no idea and I would have to do the same as you could do, too: dig in and figure out where Perl fails to load the YAML module correctly (and what the problem is). |
|
Well, like I said, the file that SVN.pm includes is present, and is very small, so about the only thing I think it can be is the require here. Presumably this is trying to load a file from the main Perl library included with the GfW installer, but as far as I can tell there is no such file -- hence the failure and fallback to Storable. I'm not sure where the msys build environment for GfW comes from (I assume this info is outdated) but that's probably where the change would have to be made, if it's desirable to get YAML supported. |
That README is about using Visual Studio IDE (via a created git.sln), or its compiler. So probably not appropriate. If you are building via the regular Makefile and the gcc compiler, then it does not apply. In addition the part of the msvc-build script (in msysgit, which automates that readme) that then calls the generator for the git.sln has bit rotted. I'm near the end of some fixes https://github.com/PhilipOakley/git/tree/msvc-build-june2015 which is 16 patches on top of the main git upstream. |
|
The build environment of Git for Windows is the Git SDK, described here: https://github.com/git-for-windows/git/wiki#about |
dscho
pushed a commit
to dscho/git
that referenced
this issue
Jul 28, 2015
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes git-for-windows#233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Aug 30, 2015
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes git-for-windows#233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Sep 10, 2015
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Sep 18, 2015
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes git-for-windows#233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Sep 29, 2015
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes git-for-windows#233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 5, 2015
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 4, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 5, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 5, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 7, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 7, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 9, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 12, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 12, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 13, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 13, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 13, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 15, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 18, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 18, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 18, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 20, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Oct 25, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes git-for-windows#233.
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Oct 25, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes git-for-windows#233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
fengguang
pushed a commit
to 0day-ci/git
that referenced
this issue
Oct 25, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes git-for-windows#233.
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 27, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 27, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[jes: fixed the commit message, made the sign-off explicit]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
gitster
pushed a commit
to git/git
that referenced
this issue
Oct 27, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes git-for-windows#233.
[ew: import "retrieve" explictly, check unlink result]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Eric Wong <[email protected]>
dscho
pushed a commit
that referenced
this issue
Oct 28, 2016
…cture
This commit overrides the original one, carried by Git for Windows for
over a year, with the version by Eric, which appears as if it should be
obviously good, and which already has been merged to upstream's `master`.
git-svn: do not reuse caches memoized for a different architecture
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[ew: import "retrieve" explictly, check unlink result]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Eric Wong <[email protected]>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Oct 29, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes git-for-windows#233.
[ew: import "retrieve" explictly, check unlink result]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Eric Wong <[email protected]>
dscho
pushed a commit
that referenced
this issue
Nov 9, 2016
Reusing cached data speeds up git-svn by quite a fair bit. However, if
the YAML module is unavailable, the caches are written to disk in an
architecture-dependent manner. That leads to problems when upgrading,
say, from 32-bit to 64-bit Git for Windows.
Let's just try to read those caches back if we detect the absence of the
YAML module and the presence of the file, and delete the file if it
could not be read back correctly.
Note that the only way to catch the error when the memoized cache could
not be read back is to put the call inside an `eval { ... }` block
because it would die otherwise; the `eval` block should also return `1`
in case of success explicitly since the function reading back the cached
data does not return an appropriate value to test for success.
This fixes #233.
[ew: import "retrieve" explictly, check unlink result]
Signed-off-by: Gavin Lambert <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Eric Wong <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This may be because I was previously using msysgit 1.9.5, but I got this error when trying a "git svn fetch" from GfW rc4 on a repository that was initially cloned using 1.9.5:
The text was updated successfully, but these errors were encountered: