git svn cygwin git-svn

git svn dcommit falla debido a un error de afirmación "svn_fspath__is_canonical(child_fspath)"(cygwin)



git-svn (9)

He experimentado lo mismo en OSX con fink, y lo resolví reduciendo svn y perl swig svn bindings a 1.7.11 desde 1.8 (y luego reconstruyendo, por si acaso, git-svn).

El problema apareció en los renombramientos, y ocurrió tanto en el servidor 1.6.12 como en 1.7.9, a través de dav_svn, en un repositorio de formato 1.6 (no estoy seguro de que suceda con svn + ssh).

git-svn está en la versión 1.8.3.3, que era un requisito en mi caso (ya que solo git-svn> = 1.7.7 puede fusionar las ramas con seguimiento de svn, consulte here ).

Espero que alguien me pueda ayudar.

Cuando trato de enviar mi rama de git local al servidor svn, esto siempre resultará en este 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

Condiciones previas:

  • limpiar el repositorio de git local (sin cambios en etapas o sin etapas)
  • llamado git svn rebase antes

La instalación de Cygwin contiene estos paquetes:

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

Al buscar este problema en Internet, encontré varios errores como este en los que no se podía canonizar un camino. Pero no encontré una solución para exactamente este problema.

¿Alguien tiene una idea de cómo resolverlo? ¿Falta alguna información?

He manejado cómo resolver este problema sin degradar svn. El mensaje de error fue así:

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...

Luego, volví a basarme justo antes de esta confirmación, eliminé File1.hpp, hice una nueva confirmación y en la siguiente simplemente agregué File2.hpp como una nueva. Después de esto, git svn dcommit ya no se quejaba.

Luché con la respuesta aceptada. Sentí que las respuestas aceptadas te dicen qué hacer, pero no cómo hacerlo. Descubrí que es mucho más fácil actualizar a la versión maestra de git que a la versión subversiva en cygwin. Tenga en cuenta que cualquiera de ellos solucionará el problema. He documentado cómo compilar la versión maestra de git aquí: ¿Cómo compilo y uso la última versión de git en cygwin?

No se garantiza que la reducción de svn ayude: el error está en el servidor backend, por lo que también hay que asegurarse de cambiar al servidor de neón.

El error se ha parchado en svn en sentido ascendente: http://thread.gmane.org/gmane.comp.version-control.subversion.devel/145186 .

Hay una solución alternativa enviada a git en sentido ascendente: http://thread.gmane.org/gmane.comp.version-control.git/237906/focus=239690 . Como está en Perl, puede aplicarlo localmente a su versión instalada, antes de que se publique cualquiera de los anteriores y se propague a su entorno.

Si no puede degradar a SVN 1.7.X, otra opción es hacer la confirmación Git-SVN de esta manera:

git svn dcommit -C1 -l1

Básicamente, esto desactiva la detección de cambio de nombre de Git (por lo que es una solución, no una solución). Perderá el cambio de nombre de la información de la pista (un cambio de nombre se confirmará como un borrado seguido de un nuevo archivo, como SVN 1.4). Pero el compromiso funcionará.

Editar A pesar de algunos comentarios aquí, creo que esto funcionará con la versión actual de Git en el repositorio de Cygwin (1.7.9.1). Si algún día eso cambia, actualizaré mi respuesta en consecuencia.

De hecho, esperemos que la situación mejore hasta el punto de que no necesitemos ninguna solución o solución, y Git-SVN simplemente funciona (como solía hacerlo). :-)

También tuve este problema (git versión 1.8.3) y lo resolví reduciendo la subversión a 1.7.9 (desde 1.8.0).

Tuve el mismo problema y lo resolví volviendo a git-svn 1.7.5.1 (svn 1.7.10).

No estoy seguro, pero creo que el problema es que el repositorio se clonó con la versión anterior de svn (1.7.xxx) y, por alguna razón, la nueva versión (1.8.0) no puede manejarlo correctamente.

Una forma fácil de instalar la versión parcheada de git-svn desde github:

  1. Encuentra el script buggy:

    find /usr -name Editor.pm

  2. Reemplácelo con la versión parcheada:

    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

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);