¿Git-svn admite diferentes revisiones para cada subdirectory?

Tengo un repository que actualmente usa Subversion, pero me gustaría usar Git localmente. Así que lo he comprobado con gitsvn:

git svn clone http://localserver/svn/repo

Ahora, dentro de Repo, tengo algunos directorys:

 repo/ trunk/ A/ B/ C/ tags/ branches/ 

El repository se encuentra actualmente en la revisión 100. Me gustaría revisar la revisión 90 dentro de repo/trunk/B y luego hacer una label para todo el repository, de modo que repo/trunk/A sea ​​rev 100, repo/trunk/B es rev 90, y repo/trunk/C es rev 100.

En svn lo haría

 cd repo/trunk/B svn update -r90 . 

¿Hay un equivalente usando git-svn, y puedo entonces hacer una label que capture el estado de todo el repository en ese momento?

Intenté esto:

 cd repo/trunk/B git svn find-rev r90 # yields 18376729f51b71212d94dcba239a2482cda9f3c8 git checkout 18376729f51b71212d94dcba239a2482cda9f3c8 . 

Y hasta donde puedo decir, los files en repo/trunk/B han cambiado según el git status , pero los files en otros subdirectorys no han cambiado. ¿Es esta la manera correcta de hacerlo, o hay una forma más "correcta"?

Como mencionó anteriormente, puede usar git checkout para hacer esto manualmente para los files en trunk/B Sin embargo, el contenido del file ahora se mostrará como modificado, y si ejecuta la git commit , volverá a enviar los contenidos de los files antiguos como files nuevos.

Por lo general, no es así como opera git, y me atrevo a decir que esto tampoco es lo que realmente quieres hacer con svn. Con git, usted quiere que todo el tree de trabajo se mueva al unísono, y como resultado, la mayoría de las veces no existe soporte para revisiones parciales o la actualización de un subtree a una versión diferente.

Cuando aparece este tipo de escenario, debe preguntarse si A , B y C son realmente "proyectos" diferentes. Cuando label, ¿los label juntos, o simplemente labelría los files de A por separado de los B ? ¿Qué hay de las ramificaciones? He encontrado que los repositorys git funcionan mejor cuando incluye todos los files que son necesarios para un proyecto, pero no más que eso. Limitar los repositorys al nivel del proyecto aumenta la contabilidad, pero también ayuda con la flexibilidad. Es por eso que verá muchas publicaciones en torno a StackOverflow sobre el uso de submodules y subtreees de git (dos conceptos distintos) para administrar grupos de repositorys.