Cómo basar una list de cambios de Perforce en otra list de cambios pendiente

Supongamos que he terminado algún código para el trabajo A, pero no puedo p4 submit hasta que el código haya sido revisado. Ahora tengo que pasar al trabajo B, que depende de los cambios que hice en el trabajo A.

¿Cómo se aseguraría que los cambios para el trabajo A se guarden para que puedan enviarse por separado más tarde (tal vez después de algunos cambios adicionales), y guarde las modificaciones del trabajo B (diff A..B) solo en una nueva list de cambios (que necesita ser astackble en algún punto para que también pueda ser revisado)?

Este es un buen caso de uso para la bifurcación. El problema con tratar de hacer todo con estantes es que las revisiones archivadas son impermanentes, por lo que no se puede tener una historia basada en ellas. Si crea una sucursal, puede aislar sus cambios de los files en los que todos los demás están trabajando, pero aún así tenerlos guardados en algún lugar permanente.

La regla de oro es "twig en política de envío incompatible". En este caso, debe enviar un trabajo no revisado (para que pueda trabajar más), pero la sucursal en la que se encuentra no permite el trabajo no revisado, de modo que haga una nueva sucursal que sí lo haga.

Asumiré para este ejemplo que estás usando streams porque hace todo más rápido; el mismo flujo de trabajo exacto ocurre con las twigs no administradas, solo hay más commands para escribir.

Asummos que está actualmente en la transmisión "principal" y tiene cambios no enviados. Trae tus cambios a una nueva twig (la llamaré "dev-bob" asumiendo que tu nombre es Bob) de esta manera:

 p4 switch -r -c dev-bob 

Ahora envíe:

 p4 submit 

Ahora adelante y haga sus otros cambios.

Para get sus cambios en "principal" y archivarlos para su revisión, haga lo siguiente:

 p4 switch main p4 merge --from dev-bob p4 resolve -am p4 shelve 

Para get todo hasta un cambio particular "A" de dev-bob agregaría "@A" al command de fusión.

Creo que eso no es posible a la fuerza.

Una solución es tener dos copys de su espacio de trabajo. Cuando haya terminado con el trabajo A, deje de lado la list de cambios en el primer espacio de trabajo. Guarde esta copy del código hasta que finalice su revisión del código.

Ahora, vaya al segundo espacio de trabajo, retire la list de cambios guardada para el trabajo A y haga los cambios que desee hacer encima del trabajo B.

Una vez que el trabajo A se envía al server, realice la synchronization p4 en el segundo espacio de trabajo y p4 diff mostrará los cambios realizados en la parte superior del trabajo A.

Si solo puedo arrojar mi opinión aquí.

Nunca debería haber una situación que le impida enviar el código. Como desarrollador, debe poder enviar el código que desee siempre que lo desee. El código debe ser revisado después de ser presentado no antes. El punto principal del control de la fuente es que controla el código fuente, una vez que el código está dentro, puede retroceder, modificarlo, eliminarlo, pero usted tiene un logging.

Si se ve obligado a saltar a través de aros para hacer algo tan básico como lo que está describiendo, entonces el flujo de trabajo en su empresa se desfigura o los administradores no entienden cómo usar forzosamente de la manera más trivial.

Hay forms muy simples de mantener su código separado hasta que haya sido revisado (las twigs son las más simples), mantenerlo fuera del control de la fuente no es una de ellas.

Imagine cómo github.com dejaría de funcionar si no pudiera registrar el código hasta que se haya revisado.

¿Ha considerado usar el soporte de Perforce para 'clon, fetch, push'?

Tanto su server como su cliente deben estar al less en 2015.1, pero una vez que lo estén, puede hacer copys clonadas del código en su estación de trabajo, enviar varios cambios al código, crear sucursales, enviar twigs o estantes a su server de revisión para su revisión. , etc.

Además de copyr los cambios entre sus clones y el server central, también puede copyr los cambios de una de sus instancias DVCS a otra, permitiendo así muchos de los flujos de trabajo DVCS que muchos desarrolladores consideran convenientes.