Open eeijlar opened 7 years ago
Luckily the branch which caused the problem is in the stack trace, so I just did:
match /branches/broken_branch_name
end match
This allowed svn2git to skip the branch and continue on with the conversion. The errant commit seems to have propagated right through the history though. It takes about 2 hours for the process to core and before you can find the branch.
See also: http://stackoverflow.com/questions/42828855/error-importing-svn-report-to-git-using-svn2git
It would be nice if it was able to log the branch that is causing trouble. It looks like it only logs the branch after it processes it.
In some cases you could be waiting for 6 hours for it to core dump, a better alternative is to do :
pstack <pid>
This should give you the branch it's currently processing, which you can then add to your rule set for skipping.
I think this maybe caused by a circular dependency within the svn commit history. For example if you have a project with /MyProject/branches/
and you create a branch off it /MyProject/branches/my_dev_branch/
Then if you copy the contents of /MyProject/branches/
into /MyProject/branches/my_dev_branch/
We have now a test harness in place. Could you maybe write a little test case that reproduces the problem?
I get a segmentation fault while processing a SVN repository. There is no information other than:
fatal: EOF in data (285 bytes remaining)
It creates a dump report but I don't know what the contents means. It prints '+' to the screen over and over and it never appears to move past that point. It's like it has encountered a circular dependency in the svn repository.
Here's the back trace from the core dump: