¿Cómo obtengo la revisión original para una twig en SVN?

De acuerdo con esta publicación del blog Este command debería decirme cuándo se release-2.0.2rc1 label release-2.0.2rc1 de protobuf:

svn log -v -r0: HEAD -l1 –stop-on-copy http://protobuf.googlecode.com/svn/tags/release-2.0.2rc1/

Sin embargo, no:

 svn log -v -r0:HEAD -l1 --stop-on-copy http://protobuf.googlecode.com/svn/tags/release-2.0.2rc1/ ------------------------------------------------------------------------ r54 | kenton@google.com | 2008-09-29 20:26:43 -0400 (Mon, 29 Sep 2008) | 3 lines Changed paths: M /tags/release-2.0.2rc1/configure.ac M /tags/release-2.0.2rc1/java/pom.xml M /tags/release-2.0.2rc1/python/setup.py Update version number in 2.0.2rc1 release branch. 

Si miro la revisión 53, obtengo la copy real:

 svn log -v -r53 -l1 --stop-on-copy http://protobuf.googlecode.com/svn/ ------------------------------------------------------------------------ r53 | kenton@google.com | 2008-09-29 20:23:29 -0400 (Mon, 29 Sep 2008) | 3 lines Changed paths: A /tags/release-2.0.2rc1 (from /trunk:52) Tagged release candidate 2.0.2rc1. 

Entonces ese command parece get la revisión después de la copy. ¿Cómo obtengo el command que me da la revisión de la twig se hizo?

Lo que estás haciendo allí es filtrar todo el espacio del repository solo a la twig que deseas y preguntar "¿cuál es la primera revisión en esa twig?". Ahora, obviamente, la revisión anterior (la que lo creó) no es parte de eso, porque la twig no existía antes de que se creara.

Entonces, lo que hace el primer command es decirte la revisión inicial que se utilizó en esa twig: la primera confirmación o copy. No le proporciona la modificación de la revisión anterior (cuando se agregó la bifurcación) porque no es una modificación de su sucursal, sino del padre. (piense en ello como que cada directory en svn no es un directory que ve en el explorador donde agregar un subdirector agrega un nuevo elemento secundario, en cambio piensa en cada directory como un file de text con una list de elementos secundarios en él)

A efectos prácticos, funciona bien, a less que desee actuar sobre los directorys padre (el directory de tags), no necesita encontrar la revisión que fue ramificada, la primera modificación de la twig es todo lo que necesita y stop-on-copy te da eso.

-l limita el número de inputs de logging que se mostrarán, por lo que si tiene más de una confirmación, solo obtendrá la confirmación más reciente. Si omite -l1 obtendrá la list completa con la última input en la que se creó la twig.

Por supuesto, su primer command habría funcionado bien si estuviera usando las tags "correctamente", es decir. solo tiene una confirmación en una label y esa es la copy donde la creó. Nunca deberías modificar una label después de eso. Piense en ellos como marcadores 🙂

Esto a veces requiere dos commands. No llegué a escribir el problema, porque mi objective era get esta información de SharpSvn, no de la línea de command de SVN. Sin embargo, el procedimiento para hacerlo desde la línea de command es el siguiente:

 svn log -v -r0:HEAD -l1 --stop-on-copy http://protobuf.googlecode.com/svn/tags/release-2.0.2rc1/ REM inspect the output and see that there is no mention of /tags/release-2.0.2rc1/ being created or copied. svn log -v -r53:0 -l1 --stop-on-copy http://protobuf.googlecode.com/svn/tags/release-2.0.2rc1/