Hello all,
While I've been working on migrating my team's SVN repository into Git, I've run into what I believe to be a bug in git-svn's fetching functionality. In particular, I'm getting output which looks like this (with the repo URL redacted):
$ git svn fetch
branch_from: /Projects/WORMS/Database_Schemas/TradeDb => /Projects/WORMS/Database_Schemas/TradeDb/tags/v12/0.12.26.0
Found possible branch point: [SVN_URL]/Projects/WORMS/Database_Schemas/TradeDb/tags/v12/0.12.26.0 => [SVN_URL]/Projects/WORMS/Database_Schemas/TradeDb_Daily/tags/v12/0.12.26.0, 68307
Initializing parent: refs/remotes/origin/tags/0.12.26.0@68307
Found possible branch point: [SVN_URL]/Projects/WORMS/Database_Schemas/TradeDb/tags/0.12.26.0 => [SVN_URL]/Projects/WORMS/Database_Schemas/TradeDb/tags/v12/0.12.26.0, 56925
Initializing parent: refs/remotes/origin/tags/0.12.26.0@56925
Found possible branch point: [SVN_URL]/Projects/WORMS/Database_Schemas/TradeDb/trunk/WormsModelDb.bak => [SVN_URL]/Projects/WORMS/Database_Schemas/TradeDb/tags/0.12.26.0, 54810
Initializing parent: refs/remotes/origin/tags/0.12.26.0@54810
Found possible branch point: [SVN_URL]/Projects/WORMS/Database_Schemas/TradeDb/WormsModelDb.bak => [SVN_URL]/Projects/WORMS/Database_Schemas/TradeDb/trunk/WormsModelDb.bak, 46608
Initializing parent: refs/remotes/origin/tags/0.12.26.0@46608
Use of uninitialized value $args[1] in join or string at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1635.
Use of uninitialized value $_[2] in exec at C:/Program Files/Git/mingw64/share/perl5/Git.pm line 1661.
fatal: Not a valid object name
ls-tree -z ./: command returned error: 128
This output is from Git version 2.24.1.windows.2 running on Windows 10 1903 and accessing an SVN repository which is, to the best of my knowledge, on version 1.9.5 (I don't have direct access to the server SVN is hosted on to check its version myself; I can follow up if the specific SVN version turns out to be relevant to the investigation). The fetch operation had been running smoothly up until I hit this error case, but now every invocation of 'git svn fetch' produces this same output.
Based on the generated output (and my very limited knowledge of Git's codebase and Perl's syntax), I believe that the problem stems from the following:
1) Within either Git::SVN::Fetcher's delete_entry or open_file function (I'm not sure exactly which, but the "ls-tree -z ./" construction appears to only come from one of those two places), the value $self->{c} is undefined
2) $self->{c} is only set in Fetcher's constructor, where it takes the value $git_svn->{last_commit}, implying that this value is also undefined
3) This value would have been set during a call to Git::SVN's find_parent_branch function if a call to find_rev_before had returned defined values
My theory, then, is that git-svn failed to find a valid parent revision, but doesn't have error-handling logic in place to handle this edge case when the SVN repository has orphaned revisions that appear to be related to the tag being processed. This would be in keeping with the behavior reported in a Stack Overflow question from 2010 (https://stackoverflow.com/questions/4367460/git-svn-fetch-fails-ls-tree-dying-because-of-missing-tree-object) featuring very similar output to what I ended up seeing.
In my case, I believe that the issue stems from the non-standard repository structure (with the 'tags' directory containing subdirectories rather than directly containing tags). The tag named '0.12.26.0' was originally created at the base level of the 'tags' directory, but later moved into the 'v12' subdirectory; it's possible that this move was somehow botched and resulted in a repository structure that git-svn isn't able to make sense of.
Assuming that my analysis is correct (and since I'm somewhat out of my depth here, it very well may not be), I would propose some combination of hardening the Fetcher against missing data, providing some sort of diagnostic warning/error message, and/or discarding orphaned SVN commits without passing them to the Fetcher to begin with, perhaps controlled by some additional switch for the fetch command.
If there's any other information I can provide that would be helpful for investigating this issue, let me know and I'll be happy to provide it.
Thanks,
Robert Miller
------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the recipients named above. If the reader of this email is not the intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and permanently delete the copy you received.
This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. Wolverine is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity that may be attached to or contained in this communication. Wolverine accepts no liability for any content contained in the email, or any errors or omissions arising as a result of e-mail transmission. Any opinions contained in this email constitute the sender's best judgment at this time and are subject to change without notice.
