RTC:La risoluzione di flusso di lacune?

Question

Ho un file di RTC (chiamata foo.c) che ho modificato e controllato in un insieme di modifiche (CS1), insieme con alcuni altri cambiamenti.Poi ho modificato il file di nuovo e controllato in un diverso insieme di modifiche (CS2) insieme ad altre modifiche.

Ora ho eseguito in un caso in cui voglio consegnare CS2 a un ruscello, ma RTC è mi dà un errore che la fornitura di che creerebbe un divario nel flusso (a causa del cambio in CS1).Non voglio consegnare tutti CS1 ancora, perché contiene alcune modifiche che non dovrebbero essere in una build di sicurezza.La modifica originale per foo.c in CS1 fu una minore rimozione di un #include, e non pregiudica niente altro.

C'è un modo per risolvere questo gap?

Vedo alcune cose nella RTC documentazione su come applicare la patch, ma non ho capito dove sta andando con questo.
C'è un modo per dividere un insieme di modifiche in più insiemi di modifiche, che mi avrebbe consentito solo per consegnare il file?

Answer 1

Aggiornamento dal 2012 (e l'originale "workaround" di consegnare tutto e il ripristino di quello che non vuoi):

Vedere questo thread:

In RTC 4.0.5 abbiamo fornito ulteriore supporto quando si tenta di accettare le serie di modifiche che hanno un gap (spesso si incontrano quando si cerca di backport correzioni).

In un breve riepilogo della funzione, quando si accetta di cambiare set con un gap, ora è possibile seguire un gap di flusso di lavoro che accetta set di una modifica alla volta e, per cambiare set di contenere lacune, crea un nuovo set di modifica (con aided tracciabilità), che contiene l'equivalente modifiche.
Questo significa che gli utenti non dovranno accettare la modifica set di "come un cerotto'.

L'applicazione di modificare i set come patch ha delle limitazioni rispetto al nuovo flusso di lavoro.
Questa funzione è riassunta nella RTC 4.0.5 'Nuovo e Degno di nota' pagina.

Qui di seguito sono alcuni video che mostrano questa caratteristica:

• Accettando più insiemi di modifiche con lacune nella RTC 4.0.5 client per l'IDE Eclipse
• Accettare una serie di modifiche con un gap RTC 4.0.5 client per l'IDE Eclipse

Che è il Individuare Insiemi Di Modifiche caratteristica:

---

In RTC 5.0 abbiamo aggiunto un "fill the gap" caratteristica in cui la serie di modifiche che, a colmare il vuoto vengono mostrati all'utente, permettendo loro di accettare tutte le serie di modifiche o di continuare con il gap di flusso di lavoro, è disponibile in RTC 4.0.5.

Questa funzione è riassunta nella RTC 5.0 'Nuovo e Degno di nota' pagina:

Le classi coinvolte per colmare il gap sono (disponibili in RTC 5.0):

client side: IWorkspaceConnection.findChangeSetsToAcceptToFillGap(...) 
server side: IScmQueryService.findChangeSetsToAcceptToFillGap(...) 

Entrambe le funzioni sono spiegate in dettaglio nel "Migliorato il Divario di Trattamento per SCM"articolo.

---

Originale risposta (2012)

C'è un modo per dividere un insieme di modifiche?

Io non la penso così, la lettura del changeset pagina man:

Un file o una cartella in una componente non può far parte di più di una serie di modifiche.
Quando un file o una cartella è contenuta in un cambiamento attivo, e in tutti i cambiamenti per diventare parte di questo cambiamento di stabilire se la modifica set corrente, e le modifiche apportate al file o cartella, non possono essere verificate in modo esplicito in un nuovo set di modifica fino a quando il cambiamento attivo che comprende completato.

Avendo pippo.c in CS1 e CS2 significa CS1 è stato "completato" (surgelati, in sostanza), e sarebbe un male per provare a dividere.

La patch soluzione:

• annullamento CS1
• aggiungere l'ulteriore modifica di pippo.c a CS2
• rifare CS1 modifiche

Vedere "Come faccio a rimuovere una serie di modifiche da un flusso?"

Storia 149483 è sul miglioramento che ingombrante flusso di lavoro, e il divario di rilevamento è stata migliorata (Valorizzazione 24822)

---

Il OP timwoj conclude:

Ho finito solo la consegna di tutti, invertendo quello che non volevo.

Answer 2

Problema: CS1 Modifica FOO.C, CS2 Ulteriori modifiche FOO.C.Vuoi solo consegnare CS2, ma RTC ti dice che introdurrebbe lacune.

Soluzione: creare una patch da CS2 e sospendere sia CS1 che CS2.Quindi applicare la patch, unirela nella tua area di lavoro e check-in le modifiche che creeranno ancora un altro set di modifiche, CS3, identico a CS2 ma senza dipendenza da CS1.Ora puoi consegnare CS3.

Dopo aver consegnato CS3, è possibile scartare CS2 e riprendere il CS1 che richiederà di fondersi con CS3.

Allora dovresti essere nello stato che CS1 si basa su CS3 e puoi scegliere se consegnare o meno CS1 in futuro.