Broken subversion support in 2.27.0.windows.1 (works in 2.26.2.windows.1)

[t-b]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version  --build-options
git version 2.27.0.windows.1
cpu: x86_64
built from commit: 907ab1011dce9112700498e034b974ba60f8b407
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.18363.836]
(c) 2019 Microsoft Corporation. Alle Rechte vorbehalten.

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Not present in portable install.

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Nope.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

git-bash.exe

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

$ git svn clone https://svn.code.sf.net/p/vice-emu/code/trunk vice-emu-code
svn: E235000: In file 'subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c' line 1666: assertion failed (get_current_pool_cb != NULL)
      0 [main] perl 1377 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

Using plain svn checkout works. I'm attaching the perl stackdump: perl.zip

• What did you expect to occur after running these commands?

working.

• What actually happened instead?

crashes.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

https://svn.code.sf.net/p/vice-emu/code/trunk vice-emu-code

I'm having the issue with a private repo, but I think any svn repo does crash.

[dex-ds]

Exactly the same issue here.

git svn info
svn: E235000: In file 'subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c' line 1666: assertion failed (get_current_pool_cb != NULL) 0 [main] perl 1783 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
git svn fetch
svn: E235000: In file 'subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c' line 1666: assertion failed (get_current_pool_cb != NULL) 0 [main] perl 1428 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
git svn rebase -v
svn: E235000: In file 'subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c' line 1666: assertion failed (get_current_pool_cb != NULL) 0 [main] perl 510 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

[Gugli]

Same here.

Reverted to 2.26.2 in the meantime, since it is a problem for me. (can confirm 2.26.2 works)
Wish you well in resolving this issue.

[dscho]

I won't lie: git svn has a pretty low priority these days.

Read: if you have any cycles to spare, I recommend using them on trying to help out here.

[escape0707]

I won't lie: git svn has a pretty low priority these days.

Read: if you have any cycles to spare, I recommend using them on trying to help out here.

Yes, but the small workspace I serve is still using SVN... What a pain... Downgrading to 2.26.2 on windows and use 2.27.0 on WSL and linux at the same time for now.

[dscho]

Well, I do have to point out that Git for Windows is open source specifically so that all users relying on specific functions can work together on it. Think of it as: "nothing is free, in open source I am paying via contributions".

[escape0707]

Well, I do have to point out that Git for Windows is open source specifically so that all users relying on specific functions can work together on it. Think of it as: "nothing is free, in open source I am paying via contributions".

I know I know. The pain I'm suffering is caused by choices of my workspace not Git for Windows. You guys have already done great works!
I must first leave this workspace to get spare time to read the code and file improvements. (But then I'll probably never use SVN anymore, so...)

[nickajordan]

Same issue here. Would love to move away from SVN completely but it's very low priority for the organisation.

[mornemaritz]

Same issue here. More ammo for me to push the suits to get rid of svn completely...

[sebrockm]

Same here. It doesn't even require a subcommand.

$ git svn
svn: E235000: In file 'subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c' line 1666: assertion failed (get_current_pool_cb != NULL)
      0 [main] perl 155 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

In case it helps, here is the dump:
perl.exe.stackdump.txt

[dscho]

Once the build finishes, this will be hopefully fixed in the Git for Windows SDK. And the next snapshot should then have the fix, too.

[dscho]

Sorry, it took a bit longer than I had anticipated to get this fixed (for a variety of reasons, not the least of which is that you gentle people left me pretty alone with the task of fixing this).

While there is no official snapshot yet, there is a build off of a PR: https://dev.azure.com/git-for-windows/git/_build/results?buildId=57380&view=artifacts&type=publishedArtifacts

Could y'all please verify that your respective git svn scenario is fixed?

[dex-ds]

While there is no official snapshot yet, there is a build off of a PR: https://dev.azure.com/git-for-windows/git/_build/results?buildId=57380&view=artifacts&type=publishedArtifacts
Could y'all please verify that your respective git svn scenario is fixed?

Thank you, works for me. I have tested the portable x64.

git --version
git version 2.27.0.windows.1.5.gaeb9254316.20200607205841

[sebrockm]

Could y'all please verify that your respective git svn scenario is fixed?

Works for me. I took installer-x86_64.
Thank you!

[nickajordan]

installer-x86_64 working for me too. Thanks very much for fixing this.

[dscho]

Thank you all for testing!

[pravic]

@dscho Any plans for a minor or a bugfix release? Because really, the 2.27.0 is literally broken now and the only option to use SVN is to rollback to 2.26.

P.S. This issue shouldn't be closed because there is no public release with the bugfix.

[dscho]

Any plans for a minor or a bugfix release?

I had plans for a bug-fix release, but I held off to gage how much it would be actually needed, and decided against it. I'll explain more about my reasoning below.

Because really, the 2.27.0 is literally broken now and the only option to use SVN is to rollback to 2.26.

That is not at all the only option. In fact, that is the worst option you have because that way, you cannot contribute to making sure that git svn works for you.

A much better option is to install the latest snapshot.

The name "snapshot" might indicate to you that this is not really robust, that it still needs some fleshing out before it can become an official Git for Windows version, but that is not at all the case. The way I run this project, I try at all times to keep the main branch in an always-releasable state. If need arises, say, today, to release a new version, e.g. if there is a zero-day in Git that we need to fix, like, Right Now, we can do that right on top of main. And that's exactly what those snapshot versions are built from, every time main changes, a new snapshot is built.

Another really splendid idea is to test those -rc versions I release before every major version. If you care to look, git svn had been broken in all of the -rc versions leading up to v2.27.0 (see e.g. v2.27.0-rc1). It was totally avoidable to have that breakage in v2.27.0. It's just that people interested in git svn support did not test it.

P.S. This issue shouldn't be closed because there is no public release with the bugfix.

Hey, if you help developing Git for Windows, you will get a say in things like this.

Right now, though, there are too few people helping, and as a consequence, I have to close tickets that are addressed from my side, otherwise I won't have any easy way to see what tickets still need my attention.

That is one of the reasons why I introduced those snapshot versions: so that people who report bugs that have been fixed can unblock themselves by (temporarily) switching to a snapshot release.

[pravic]

First of all, a big thank you for the explanation.

1. Having a snapshot instead of a hotfix release is.. well, okay - at least, it allows us to continue our work. Because I really could not find anything downloadable in the link mentioned above: https://dev.azure.com/git-for-windows/git/_build/results?buildId=57380&view=artifacts&type=publishedArtifacts

2. As for the testing -rc versions.. It's the same as for alpha/beta/nightly versions - some people use them, some - don't.

I have to close tickets that are addressed from my side, otherwise I won't have any easy way to see what tickets still need my attention.

3. I'd create a separate label or would use milestones - and I'd close the marked issues after publishing a release (or RC).

[dscho]

I have to close tickets that are addressed from my side, otherwise I won't have any easy way to see what tickets still need my attention.

3. I'd create a separate label or would use milestones - and I'd close the marked issues after publishing a release (or RC).

I'll take that under advice :-)

[Bidthedog]

I've experienced this with the 2.27.0.windows.1 release too - both of the following commands fail.

Context: I'm currently putting together a really complex, one-way migration, though it's taking a good while to get "signed off" at present, so I still need SVN support for now:

git svn clone <svnrepo> --username=<username> --prefix=<myprefix>/ --trunk=<SVNtrunk> --no-metadata --authors-file=<path_to_authors_file>

Errors with:

svn: E235000: In file 'subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c' line 1666: assertion failed (get_current_pool_cb != NULL)
0 [main] perl 1854 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

git svn fetch --authors-file=<path_to_authors_file>

Errors with:

vn: E235000: In file 'subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c' line 1666: assertion failed (get_current_pool_cb != NULL)
0 [main] perl 92 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

I'm downgrading back to .26 for now until there is an official release.

[dscho]

I'm downgrading back to .26 for now until there is an official release.

@Bidthedog if you want to make sure that a new official release will work for you, you will at least test the prerelease.

[nrbray]

Thank you it is fixed for me in latest snapshot. Tue, 7 Jul 2020 22:01:58 +0200 Portable Git (self-extracting .7z archive): 64-bit

[dscho]

@nrbray excellent. Thank you for testing, this fills me with more confidence about v2.28.0.

[aolszowka]

@dscho

I held off to gage how much it would be actually needed, and decided against it

Chiming in to say we are affected by this issue in case that makes a difference to you (Medium Sized Company, 60 Devs/maybe 5-10 using the bridge right now).

I have upgraded to the latest snapshot (July 7th) and can confirm this works/fixes the issue.

Right now, though, there are too few people helping, and as a consequence, I have to close tickets that are addressed from my side, otherwise I won't have any easy way to see what tickets still need my attention.

I thank you from the bottom of my heart (as I am sure the rest of the people that work with me would as well). I know that maintaining these types of open source projects can be thankless (as evident by some of the comments in here). I just want to pipe up and say you are an awesome person and ignore the haters.

FWIW we are using the bridge as a stop gap, we're trying to get to full blown git, but I am not confident we will get there, this bridge gives us a way to at least get SOME wins...

[dscho]

@aolszowka thank you so much for your kind words!

As to your situation, I understand, I really do. I, too, have been in situations where there the best available option was still a sub-optimal one, and the best one could do was to accept that and chug along "until spring, when the grass got greener".

FWIW it currently looks as if Git for Windows v2.28.0-rc1 will have to wait until tomorrow because Git v2.28.0-rc1 might be delayed by a day (it was originally slated for today). Please do upgrade to -rc1 once it is available, and feel free to report any bugs you encounter.

[Bidthedog]

@dscho Apologies, I just wanted to provide some objective feedback - I was under a lot of pressure to get some post-migration binaries out to QA the other day, and the bug caused me to have to re-run a 7+ hour migration (and I don't get any feedback during the execution either!):

10:46:47.4010 - [Customer.Product] GIT EXECUTE 'git svn clone http://svn.Customer.com:8080/svn/Customer/Production/Products/Product Customer.Product.svn --username=Customer\username --prefix=svn/ --trunk=http://svn.Customer.com:8080/svn/Customer/Production/Products/Product/trunk --no-metadata --authors-file=D:\Git\Clients\Customer\Customer-migration\users-git.txt' in 'D:\Git\Clients\Customer\Customer-migration\.migration-root\git-sync'
16:49:15.0060 - [Customer.Product] $ Initialized empty Git repository in D:/Git/Clients/Customer/Customer-migration/.migration-root/git-sync/Customer.Product.svn/.git/

~20 years of history being migrated! I'm sure you can imagine how many moving parts the migration has and how complex it is; and this is just the first step! Hell of a long time to wait hoping it's all still working! Luckily it was :)

I have now installed v2.28.0-rc1 (x64 .exe installer) and re-tested; I can't test clone (would take another 6 hours), but fetch seems to be working fine again:

08:53:36.5696 - [Customer.Product] GIT EXECUTE 'git svn fetch --authors-file=D:\Git\Clients\Customer\Customer-migration\users-git.txt' in 'D:\Git\Clients\Customer\Customer-migration\.migration-root\git-sync\Customer.Product.svn'
08:53:44.6769 - [Customer.Product] $ 	M	make/makefile.cmd
08:53:44.6785 - [Customer.Product] $ r41959 = 22455063fb15b60e7dd24d0dcbdfc62a918780d7 (refs/remotes/svn/trunk)

All your efforts are greatly appreciated - git is a wonderful tool, and I am a massive advocate of its use (I am actually giving some advanced git training next week as part of this migration) and if I had even the slightest bit of C++ experience I'd offer to help, but I am but a mere C# dev!

<3 to you and all the git collaborators :)

[f18a14c09s]

How was this bug not caught prior to release of the "most recent maintained build"? git svn is completely broken in Git for Windows 2.27.0, right?

[aolszowka]

@f18a14c09s chances are there is not an automated test as this is an uncommon scenario.

It's an open source project you're more than welcome to submit a Pull Request that includes robust integration testing for this feature if it is so critical to your work flows that you cannot be down.

Until then you can either:

1. Rollback to 2.26.2
2. Roll Forward to the latest Prerelease which has been shown to work by numerous people here.

To quote Jim Gettys "I recommend you be happy we have a bus"

[luiscla27]

I had troubles finding the 2.62.2 installer, here it is for everyone else:
https://www.npackd.org/p/git64/2.26.2

[escape0707]

https://github.com/git-for-windows/git/releases This link also appears in the beginning part of the download link in the webpage you provided. :)

…

On Tue, Jul 21, 2020 at 12:56 AM Luis Carlos Limas ***@***.***> wrote: I had troubles finding the 2.62.2 installer, here it is for everyone else: https://www.npackd.org/p/git64/2.26.2 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2649 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUBEWMJZOPA4NDNMCTCV33R4RZMPANCNFSM4NQFWVEQ> .

[dscho]

Please don't link to npackd.org. The official releases can all be found from the "All releases" link on the bottom of https://gitforwindows.org/.