¿Por qué todas las líneas devueltas por `svn blame Foo.cs` en blanco?

Tengo un file en mi repository de Subversion llamado "Foo.cs". Cuando ejecuto el command svn blame Foo.cs la salida se ve así:

 1000 dave 1000 dave 2000 dave 2000 dave 9999 dave 1000 dave 9999 dave 

Lo único que se me ocurre es que a partir de las revisiones 1000-9000, Foo.cs tenía la propiedad "svn: mime-type" establecida en "application / octet-stream". Sin embargo, desde r9000 Foo.cs no tiene tal propiedad ya que es (y siempre ha sido) un file de text.

Además, ya he intentado usar svn blame Foo.cs --force sin éxito.

¿Alguien sabe cómo arreglar este problema?

EDITAR: En r1000, el historial se truncó ( svn log Foo.cs no informa nada antes) porque la twig se movió a un lugar diferente en el repository a mano en lugar de usar svn mv . Sin embargo, es difícil imaginar que esta es la causa del problema porque svn blame funciona en todos los demás files en el repository.

Lo único que se me ocurre es que a partir de las revisiones 1000-9000, Foo.cs tenía la propiedad "svn: mime-type" establecida en "application / octet-stream". Sin embargo, desde r9000 Foo.cs no tiene tal propiedad ya que es (y siempre ha sido) un file de text.

Creo que esa es tu respuesta. Experimentando con Subversion 1.6, cada vez que tengo una revisión en la historia con svn:mime-type establecido en application/octet-stream , obtengo Skipping binary file from svn blame .

Es posible que Subversion haya establecido la propiedad automáticamente , si detectó que el file tiene contenido que no es de text.

No puedo pensar en una buena respuesta para arreglar la situación. Puede eliminar y volver a agregar el file nuevamente. Esto truncará la historia, pero al less svn blame funcionará para revisiones más recientes.

Probablemente encuentre su respuesta mirando lo que sucedió en los numbers de cambio 9999 y 2000. O simplemente mire todos los cambios para el file ( svn -log -v Foo.cs ) y vea si otras properties pudieron haber sido cambiadas .

    Intereting Posts