17

I hope anybody can help me.

When I try to push my local git branch to the svn server this will always result into this error:

$ git svn dcommit
Committing to http://.../Dev_Stream/01_workspace ...
    C      path/to/file/AbstractSystemThread.java => other/path/to/file/Thread/AbstractThread.java
assertion "svn_fspath__is_canonical(child_fspath)" failed: file "/usr/src/subversion/subversion-1.8.0-1/src/subversion-1.8.0/subversion/libsvn_subr/dirent_uri.c", line 2502, function: svn_fspath__skip_ancestor

Preconditions:

  • clean local git repository (no staged or unstaged changes)
  • called git svn rebase before

Cygwin installation contains these packages:

  • git, git-svn 1.7.9-1
  • subversion, subversion-perl 1.8.0-1

When searching for this problem in the internet, I found several errors like this where a path could not be canonicalized. But I did not find a solution for exactly this problem.

Has anybody an idea how to solve it? Is any information missing?

svick
  • 236,525
  • 50
  • 385
  • 514
gofabian
  • 263
  • 3
  • 6
  • I have the same problem and don't know the solution yet. But just to check for similarities: I am using a self-compiled git 1.8.3, but my svn is the same as yours. Do you use Eclipse 4.3 (kepler) with git tooling installed? I have never had any problems while still using juno. Maybe kepler is causing some trouble here. – Tobias Schulte Jul 18 '13 at 08:11
  • In the meantime I was able to commit using a linux virtual machine and sharing the projects-folder. Just remember to do "git config core.filemode false" if you don't want to commit file attribute changes. In my case the error did also happen after renaming of a file. But in a clean workspace renaming did work. – Tobias Schulte Jul 19 '13 at 06:42

9 Answers9

13

If you cannot downgrade to SVN 1.7.X, another option is doing the Git-SVN commit this way:

git svn dcommit -C1 -l1

This basically turns off Git rename detection (so it is a workaround, not a fix). You will lose rename track information (a rename will be committed as a delete followed by a new file, like SVN 1.4). But the commit will work.

Edit In spite of some comments here, I believe this will work with the current Git version on the Cygwin repository (1.7.9.1). If some day that changes, I'll update my answer accordingly.

In fact, let's hope the situation improves to the point that we won't need any fix or workaround, and Git-SVN just works (as it used to). :-)

rsenna
  • 11,775
  • 1
  • 54
  • 60
  • THANK YOU! I was struggling with this for a while. Downgrading did not work, but this...this is perfect. – Emilis Panovas Jan 14 '14 at 15:14
  • 2
    This worked perfectly for me. It might not be the best option but it worked! – bdowden Jan 22 '14 at 13:39
  • Doesn't work with git 1.8.4.5 and svn 1.8.5. Patching Editor.pm is a better solution. – alexanderlukanin13 Feb 10 '14 at 10:53
  • In your own words: "This basically turns off Git rename detection (so it is a workaround, not a fix)". That's why patching is "better" - because it fixes the core problem. I think proper fix is always better than a workaround when the effort is comparable. And I wouldn't even call the workaround "faster" because: a) it doesn't work for some versions, so for some people it will be a waste of time trying b) someday problem will rise again and it will be a frustrating interruption of a workflow. – alexanderlukanin13 Feb 26 '14 at 07:53
  • And just from my personal experience: when your tools become goddamned and bloody, it's a sign of bad development practices :-) – alexanderlukanin13 Feb 26 '14 at 07:54
  • @alexanderlukanin13: Exactly, I told from the beginning this is a workaround. So, If you want a "better" option, that's fine with me. – rsenna Feb 26 '14 at 19:14
  • @alexanderlukanin13: And by the way: why are you talking about Git 1.8.*, considering that a) this is a **Cygwin** thread, and b) currently **the last Git version on the official Cygwin repository is 1.7.9.1**???? – rsenna Feb 26 '14 at 19:30
7

I also had this problem (git version 1.8.3) and solved it by downgrading subversion to 1.7.9 (from 1.8.0).

Peter Dinges
  • 86
  • 2
  • You are right. I solved it the same way with svn package version 1.7.10. A provider for old package versions is www.fruitbat.org – gofabian Sep 04 '13 at 18:00
  • 1
    How can I downgrade cygwin subversion? – ruseel Sep 09 '13 at 09:04
  • 1
    Go to http://www.fruitbat.org/Cygwin/ and look at the "Cygwin Time Machine". There you will find several outdated cygwin download sites. – gofabian Oct 04 '13 at 05:39
  • 1
    @fabianheld That website has a ton of noise, it's really hard to figure out what to do. 32bit version: ftp://www.fruitbat.org/pub/cygwin/circa/index.html 64bit version: ftp://www.fruitbat.org/pub/cygwin/circa/64bit/index.html – Daniel Kaplan Jan 09 '14 at 00:58
  • This is the first I found with subversion 1.7.9: ftp://www.fruitbat.org/pub/cygwin/circa/2013/04/21/134005/index.html That means you should use `ftp://www.fruitbat.org/pub/cygwin/circa/2013/04/21/134005` in your setup.exe like so: http://imgur.com/faNR5fR – Daniel Kaplan Jan 09 '14 at 01:05
4

An easy way to install patched version of git-svn from github:

  1. Find the buggy script:

    find /usr -name Editor.pm

  2. Replace it with patched version:

    cd /usr/lib/perl5/vendor_perl/5.18.1/Git/SVN
mv Editor.pm Editor.pm.bak
wget https://raw.github.com/git/git/2394e94e831991348688831a384b088a424c7ace/perl/Git/SVN/Editor.pm
alexanderlukanin13
  • 4,577
  • 26
  • 29
3

I've managed how to solve this problem w/o downgrading svn. Error msg was like this:

git svn dcommit
Committing to http://...
        C       File1.hpp => File2.hpp

ERROR from SVN:
RA layer request failed: PUT request on '...File2.hpp' failed: 409 Conflict...

then I've rebased just before this commit, removed File1.hpp, made new commit and in next one just added File2.hpp like a new one. After this git svn dcommit wasn't complaining anymore.

ptw
  • 31
  • 2
  • Thank you, thank you, thank you! This solved the problem for me too. I had actually done the delete in one commit, the add in the next commit, and then used interactive rebase to squash into one commit which resulted in Git interpreting it as a rename. So I used the reflog to find my pre-squashed commits, reset master onto them, and my git svn dcommit just worked! – Oran Dennison Sep 12 '13 at 21:10
  • I think this is only a workaround, but does not solve the problem. Furthermore your error seems not to be the same issue as mine. – gofabian Oct 04 '13 at 05:56
  • +1: the accepted solution is *also* an workaround, but this one is much more acceptable (I cannot downgrade SVN). – rsenna Oct 29 '13 at 21:56
  • I think this is not the same problem. The error message is completely different. Therefore this is not the accepted solution. The accepted solution actually is not a soluation. The solution would be to solve the bugs in the git/svn code. – gofabian Nov 28 '13 at 09:30
  • The error message shown in this answer is, indeed, distinct from what the OP has reported. Nevertheless, I'm getting exactly the same error as the OP, and this solution **does** work. Agreed, it is a workaround, but all answers here are. BTW, I'm just adding another, easier one :P – rsenna Dec 21 '13 at 00:58
  • @rsenna: if downgrading allows him to dcommit renamed/move files, I'd say it's a better solution than this. My understanding is this solution will lose history. – Daniel Kaplan Jan 09 '14 at 01:09
  • @tieTYT: yes, this solution will lose history (but only on renaming), and I agree this can be a problem. Still, there are cases when you just cannot downgrade. So I'm not arguing which one is a "better" solution (since it depends on context); what I'm saying is that neither is good enough to be *the* answer. – rsenna Jan 14 '14 at 19:22
  • @rsenna check out my answer below. The solution is to upgrade git to a version without this issue. – Daniel Kaplan Jan 14 '14 at 19:28
  • @tieTYT: building Git from source is what I end up doing too. But this solution has its own issues: for instance, you become unable to install any Cygwin package that depends on Git (unless you're ok in having 2 distinct Git versions side-by-side). I did ask [here on SO](http://stackoverflow.com/questions/19183329/how-can-i-tell-cygwin-that-a-dependency-was-built-from-source) if there is any way of fixing that, but I was not lucky (maybe you know some way?). – rsenna Jan 14 '14 at 19:58
  • @rsenna no idea, sorry – Daniel Kaplan Jan 14 '14 at 19:59
2

Downgrading svn is not guaranteed to help: the bug is in serf backend so one has to also make sure to switch to neon backend.

The bug has been patched in svn upstream: http://thread.gmane.org/gmane.comp.version-control.subversion.devel/145186.

There's a workaround submitted to git upstream: http://thread.gmane.org/gmane.comp.version-control.git/237906/focus=239690. As it's in perl you can apply it locally to your installed version, before any of the above is released and propagates to your environment.

rkagan
  • 21
  • 1
1

I have experienced the same on OSX with fink, and solved it by downgrading svn and the perl swig svn bindings to 1.7.11 from 1.8 (and afterwards rebuilding, just in case, git-svn).

The problem appeared on renames, and happened both on server 1.6.12 and 1.7.9, via dav_svn, on a 1.6 format repository (I am unsure if it happens with svn+ssh as well).

git-svn is on version 1.8.3.3, which was a requirement in my case (as only git-svn >= 1.7.7 can merge svn-tracked branches, see here).

Jisakiel
  • 11
  • 1
1

I struggled with the accepted answer. I just felt like the accepted answers tells you what to do but not how to do it. I found it much easier to upgrade to the master version of git than downgrade subversion in cygwin. Keep in mind either one will fix the issue. I've documented how to build the master version of git here: How do I build and use the latest version of git on cygwin?

Community
  • 1
  • 1
Daniel Kaplan
  • 62,768
  • 50
  • 234
  • 356
0

I had the same problem and solved it by reverting to git-svn 1.7.5.1 (svn 1.7.10).

Not sure but I think the problem is that the repository was cloned with the previous version of svn (1.7.xxx) and for some reason the new version (1.8.0) cannot handle it correctly.

Andrea Polci
  • 1,011
  • 13
  • 27
0
diff -u  /usr/local/lib/perl5/site_perl/5.16/Git/SVN/Editor.pm.bak  /usr/local/lib/perl5/site_perl/5.16/Git/SVN/Editor.pm    
--- /usr/local/lib/perl5/site_perl/5.16/Git/SVN/Editor.pm.bak   2014-01-20 15:52:54.000000000 +0100
+++ /usr/local/lib/perl5/site_perl/5.16/Git/SVN/Editor.pm       2014-01-20 15:55:16.000000000 +0100
@@ -304,8 +304,9 @@
        my ($self, $m, $deletions) = @_;
        my ($dir, $file) = split_path($m->{file_b});
        my $pbat = $self->ensure_path($dir, $deletions);
+       my $upa= $self->url_path($m->{file_a});
        my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
-                               $self->url_path($m->{file_a}), $self->{r});
+                               $upa, $self->{r});
        print "\tC\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
        $self->chg_file($fbat, $m);
        $self->close_file($fbat,undef,$self->{pool});
@@ -323,8 +324,9 @@
        my ($self, $m, $deletions) = @_;
        my ($dir, $file) = split_path($m->{file_b});
        my $pbat = $self->ensure_path($dir, $deletions);
+       my $upa= $self->url_path($m->{file_a});
        my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
-                               $self->url_path($m->{file_a}), $self->{r});
+                               $upa, $self->{r});
        print "\tR\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
        $self->apply_autoprops($file, $fbat);
        $self->chg_file($fbat, $m);
pierre
  • 1