Perché si dovrebbe evitare l'unione incrociata (circolare) nel controllo della versione a squadre multiple?

7

Scusate l'opera d'arte, so che sembra una navetta imperiale allungata, ma è il modo in cui visualizzo una strategia di controllo della versione di più team (o più stream). Il nucleo centrale, è il deposito del tronco (o master). Se ci sono molti più flussi puoi immaginare più piani che escono dal tronco, in cui varie ramificazioni e fusioni si svolgono all'interno di quei flussi (le linee più sottili).

La linea rossa mostra i pidocchi A dalla contabilità che vogliono prendere un pezzo di codice che B ob dal team di backup ha appena falsificato (ne ha bisogno urgentemente per alcuni motivo a cui non riesco a pensare). In realtà, non è come un cambiamento di linea che lei può solo fare da sola. Invece, puoi considerare che la contabilità è pesantemente bloccata e che è necessario un grande set di modifiche da Backup per continuare.

Ora, a quanto ho capito, questo è contro la best-practice, e le modifiche richieste dovrebbero passare attraverso il trunk, e Alice dovrebbe prenderle in questo modo, piuttosto che prendere la scorciatoia illustrata (un wormhole di controllo della versione). Tuttavia, sebbene l'abbia visto in vari punti, non ho mai visto ragioni profonde, lunghe e ben giustificate per le quali una fusione incrociata (o circolare?) È qualcosa da non consentire. L'unica cosa che posso pensare è che immagino possa portare a una maggiore risoluzione dei conflitti manuali.

Quindi le domande sono:

  • Perché consentire l'unione di un flusso incrociato errato? (Ho bisogno di alcuni ben definiti motivi per convincere i miei colleghi che hanno una mentalità varia perché non dovrebbe essere fatto)
  • Ci sono motivi giustificabili per andare contro la best practice?
  • Che cosa succede se il team di Alice sta raggiungendo una scadenza di rilascio, può esserci un? eccezione?
posta Benedict 25.10.2011 - 12:57
fonte

2 risposte

1

Dopo aver letto la documentazione di ramificazione e fusione TFS non sono riuscito a trovare una risposta sensata per il tuo domande. Secondo il doc è perfettamente accettabile avere diversi flussi di sviluppo su un prodotto nelle proprie filiali. Immagino che i migliori argomenti contro questo scenario siano:

  • maggiore complessità nella fusione e risoluzione dei conflitti su più flussi alla radice
  • possibilità di sovrapposizione del lavoro (più team potrebbero risolvere lo stesso problema in modo diverso)
  • suddividere gli sforzi di sviluppo su vari team e coordinare tale sforzo richiede una buona comunicazione e una gestione del cambiamento tra i team

Quindi quando lo guardi, non è un problema di tecnologia che "blocca" questo scenario.

    
risposta data 25.10.2011 - 14:56
fonte
1

Now as I understand it, this is against best-practice, and the changes required should go through the trunk, and Alice should pick them up that way, rather than take the short cut illustrated

Perché così ??? Il compito finale è (dopo tutto) ottenere il prodotto, non seguire ciecamente la politica. La comunicazione tra team è buona, se serve il compito finale - "fare le cose"

    
risposta data 26.10.2011 - 06:21
fonte

Leggi altre domande sui tag