git svn clone fails

Hello guys,

we have to turn some projects managed by Subversion into a GIT-based solution. However the conversion unfortunately fails with an error:

============== %< ==============
[...]
Found branch parent: (refs/remotes/origin/tags/v_2.1.1) 
450fa2c84a8fc087a2a66e5fb3d6d22096671f81
Following parent with do_switch
        M       changes.xml
        M       pom.xml
couldn't truncate file at /usr/lib64/perl5/vendor_perl/5.20.2/Git.pm line 
1325.
$ git --version
git version 2.5.0
============== %< ==============

Apart from the line number, the same error occurs also with GIT version 2.4.6 and 2.3.6 (latest stable version in Gentoo).

The command to create the GIT repository was: ============== %< ============== $ git svn clone http://websvn/svn/essvn/standard/java-commons/lang -s --no- metadata --preserve-empty-dirs -A ~/tmp/authors.txt commons-lang ============== %< ==============

Note, that the command succeeds even for 2.4.6 if we drop the --preserve- empty-dirs option - at the cost of some empty directories which are used to trigger profiles for Maven; i.e. without those we cannot reproduce released versions.

Cheers, Jörg

Hmmm. Is this the proper channel to report issues or should I go somewhere else?

Jörg Schaible wrote:

Is there really no other place for a bug report? This will simply vanish in the list's noise ...

Jörg Schaible wrote:

On 2015-08-14 09.51, Jörg Schaible wrote: I can't reproduce it here:

 git svn clone http://websvn/svn/essvn/standard/java-commons/lang
Initialized empty Git repository in /home/xx/lang/.git/
RA layer request failed: OPTIONS of
'http://websvn/svn/essvn/standard/java-commons/lang': Could not resolve hostname
`websvn': Host not found (http://websvn) at
/Users/xx/lib/perl5/site_perl/Git/SVN.pm line 143

In other words, is there a way to make this reproducible for others? If not, how could the problem be tracked down and fixed (from other people than you or somebody in your organization ?)

Hi Torsten,

thanks for an answer ...

Torsten Bögershausen wrote:

It is unfortunately not possible to provide this Subversion repo to the 
public.
 

Actually I hoped, that my report raised some memories, because errors with this symptom had been examined before and some kind of fix has been added (according http://stackoverflow.com/questions/25353316/error-with-git-svn-clone) to GIT 2.4.x. However, it seems there's still an issue even in GIT 2.5.0 when the svn repo contains empty directories that have to be preserved ...

Actually I am not sure. I tried to create a little dummy project in a Subversion test repository that contains also empty directories which have to be preserved ... but the conversion for it works flawlessly. Even if those dirs had been nested, renamed, moved and deleted.

Any idea how to proceed?

Cheers, Jörg

On 2015-08-14 12.38, Jörg Schaible wrote:

Git itself doesn't version empty directories at all, only files (and soft links, sub modules....).

Git creates a directory as a "side effect" to be able to store files there.

May be I am off-topic, but would it be possible to fill the empty directories with a dummy file ".empty" ? Add those to svn and force Git to create a nearly empty directory.

Hi Thorsten,

there's more fun though. GIT (2.4.6) fails differently if I add additionally the "--no-minimize-url":

==================== %< =================
[...]
W: -empty_dir: trunk/src/test/serialization/com/elsagsolutions
r40223 = 7983efa910e6cd606cc63a6b6b365048df1e11a9 
(refs/remotes/origin/trunk)
        M       src/main/java/com/scalaris/commons/lang/util/ArrayUtils.java
r40261 = ecf4747a88073353c9731e6e69c079d66e7aac2d 
(refs/remotes/origin/trunk)
        M       
src/test/java/com/scalaris/commons/lang/util/ArrayUtilsTestCase.java
r40262 = 96eda7427de3f1c082e88c23458be197a3b20a7a 
(refs/remotes/origin/trunk)
        M       changes.xml
        A       src/main/java/com/scalaris/commons/lang/net/MimeTypes.java
r41127 = 00d0a652e5ef20c18b9d4764dd70383c1d10177b 
(refs/remotes/origin/trunk)
        M       changes.xml
Failed to strip path 
'src/main/java/com/elsagsolutions/commons/lang/io/.gitignore' ((?^:^trunk(/|
$)))
==================== %< =================

the error in the Perl module happens only without that option. Both errors do not occur without option "--preserve-empty-dirs".

Torsten Bögershausen wrote:

I know, but "git svn clone" creates a .gitignore file in such a case.

That does not help when converting the Subversion history. It's failing long before HEAD of trunk.

That's what GIT normally does by default on its own. However, I cannot change the Subversion history. GIT has to deal with it while converting (and normally it does, as my test proofed with the demo Subversion project).

Cheers, Jörg

Jörg Schaible <joerg.schaible@swisspost.com> wrote:

These messages do get seen and read. (And I would not have seen this message if it were posted anywhere else).

But I don't have much time or motivation to work on git svn since it's mostly made itself obsolete for me.

--preserve-empty-dirs probably hasn't seen much real-world use and (IIRC) not something that could always be 100% reliable.

Regardless of options, git svn does log empty directories, so there's also an obscure, probably equally-unused "git svn mkdirs" command which processes the unhandled.log files inside $GIT_DIR to recreate empty directories. You could give that a try.

Hi Eric,

Eric Wong wrote:

As first time poster for this list without any response in days I was simply not sure, if it was the correct place to report problems.

That's our goal also, to make svn obsolete ;-)
All we need is a one time conversion.
 

I am not sure, what you actually try to tell me here. How can I interfere in the complete "svn clone" process?

Note, that the problem seems really to be caused by some obscure condition. We can actually clone some svn trees that contain empty directories and they are properly handled with a .gitignore file. However, some fail for unknown reason.

I tried to recreate the situation with a separte non-critical svn playground, but was never able reproduce the problem. svn clone succeeded every time. Not very useful for an error report, I know. :-/

Cheers, Jörg