Gli alias sono nomi brevi in grado di identificare gli elementi nel controllo origine. Gli alias sono numeri a quattro cifre (tra parentesi) che sono visualizzati alla sinistra dell'elemento prescelto. Ad esempio:
$ scm status
Spazio di lavoro: (6377) "My Workspace" <-> (7487) "Stream"
Componente: (6429) "Flux Capacitor"
Baseline: (8471) 6815 "v20091102"
In uscita:
Serie di modifiche:
(8459) --@ 98314 "Degauss Flux Capacitor" - <No comment>
Nell'esempio in alto, ogni numero tra parentesi (6377, 7487, 6429, 8471, 8459) è un alias.
Ciascun sottocomando dispone di un insieme di codici di ritorno. Se il sottocomando ha esito positivo viene restituito 0. Al contrario, viene restituito un valore diverso da zero quando si verifica un errore o un problema, come ad esempio un conflitto o la mancata sincronizzazione del sandbox locale con lo spazio di lavoro remoto.
Gli esempi riportati di seguito presuppongono l'accesso al repository come lscm login. Pertanto, sarà necessario aggiungere -r repositoryNickName con ciascun sottocomando. Ad esempio:
$ lscm login -r https://your.repository.com:9443/jazz -n nickname -u echughes -c Password (echughes @ https://your.repository.com:9443/jazz): Logged in to https://your.repository.com:9443/jazz
È inoltre possibile fare riferimento al repository https://your.repository.com:9443/jazz con un nome alternativo. Ad esempio, passare -r nickname al sottocomando, invece di URL, nome utente e password.
Prima di iniziare un progetto, è necessario disporre di un nome utente, una password, e l'URL del repository. Sarà inoltre necessario che l'utente sia membro di un'area team.
Se si ignora il nome del flusso a cui si sta collaborando, è possibile utilizzare lscm list streams -r nome alternativo per ottenere l'elenco dei flussi a cui si ha accesso. Ad esempio:
$ lscm -a y list streams -r l DeLorian Upgrades Home Energy Converter Doc Brown's playpen
Una volta trovato il nome del flusso a cui si collabora, è possibile creare uno spazio di lavoro remoto che includa le modifiche eseguite. Ad esempio:
$ lscm create workspace -r l myNewWorkspace -s "DeLorian Upgrades" Spazio di lavoro (8551) "myNewWorkspace" creato
Aggiungendo il parametro -s è possibile specificare il flusso con cui lo spazio di lavoro dovrà collaborare. Il nuovo spazio di lavoro adotterà quel flusso come destinazione flusso predefinito e assumerà come stato iniziale lo stato del flusso.
Per caricare lo spazio di lavoro remoto:
$ lscm load myNewWorkspace -r l Download in corso di /flux.capacitor/requirements.txt (0 B) Download in corso di /flux.capacitor/diagrams/design.cad (0 B)
Da un controllo origine CLI, è possibile seguire un flusso di lavoro tipico, come ad esempio, modifica dei file, check-in dei file e accettazione delle nuove modifiche e trasferimento delle modifiche.
Le azioni di check-in e trasferimento in CLI sono identiche a quelle del client Eclipse. La prima sposta le modifiche dal disco locale allo spazio di lavoro remoto; la seconda sposta le modifiche dallo spazio di lavoro remoto al flusso.
Nel seguente esempio CLI, vengono modificati diversi file e si individuano quelli modificati eseguendo il comando status:
$ lscm status
Spazio di lavoro: (8551) "myNewWorkspace" <-> (8552) "DeLorian Upgrades"
Componente: (8553) "Flux Capacitor"
Baseline: (8554) 1 "Initial Baseline"
Non risolto:
-c /flux.capacitor/requirements.txt
In uscita:
Serie di modifiche:
(8555) --$ "Initial CAD"
Il comando status ricerca le modifiche in tutte le directory condivise e questa operazione potrebbe richiedere del tempo. Se si desidera unicamente visualizzare il confronto dello spazio di lavoro remoto con il flusso, è possibile eseguire lscm status –n, che evita l'esame del disco locale.
Per eseguire il commit delle modifiche, utilizzare lscm checkin:
$ lscm checkin flux.capacitor/
Esecuzione del commit in corso...
Spazio di lavoro: (8551) "myNewWorkspace" <-> (8552) "DeLorian Upgrades"
Componente: (8553) "Flux Capacitor"
In uscita:
Serie di modifiche:
(8556) --@ <Nessun commento>
Questo esempio crea una nuova serie di modifiche in modo implicito. Nell'output vengono elencate le serie di modifiche che hanno ricevuto i file e le cartelle durante l'esecuzione del commit.
Una volta completata la creazione della serie di modifiche, è possibile associarlo con un elemento di lavoro e aggiungere un commento. Per assegnare un elemento di lavoro, utilizzare il comando lscm changeset associate. Per impostare il commento, utilizzare il comando lscm changeset comment.
È possibile visualizzare periodicamente lo stato di un flusso, eseguendo il comando lscm status:
$ lscm status -C
Spazio di lavoro: (8551) "myNewWorkspace" <-> (8552) "stream19_test_max_results_1256765247692134"
Componente: (8553) "Flux Capacitor"
Baseline: (8554) 1 "Initial Baseline"
In uscita:
Serie di modifiche:
(8556) --@
Modifiche:
---c /flux.capacitor/requirements.txt
In entrata:
Serie di modifiche:
(8615) --$ "Initial layout"
Modifiche:
---c /flux.capacitor/diagrams/design.cad
Il flag -C mostra i contenuti delle serie di modifiche.
Nell'esempio precedente, è stata rilevata un'unica modifica in entrata in design.cad. È possibile accettare questa modifica perché non comporta alcuna modifica ai file della serie di modifiche.
Eseguire il comando lscm accept:
$ lscm accept -v
Repository: https://localhost:9443/jazz/
Spazio di lavoro: (8551) "myNewWorkspace"
Componente: (8553) "Flux Capacitor"
Serie di modifiche:
(8615) ADMIN --$ "Initial layout"
Modifiche:
--c /flux.capacitor/diagrams/design.cad
Occasionalmente, le modifiche in entrata comportano modifiche dei file già modificati in precedenza.
Nell'esempio che segue, flux.capacitor/requirements.txt viene modificato in modo da includere una nota dalla pianificazione di un meeting, eseguire il check-in del file ed eseguire il controllo di stato:
$ lscm status -C
Spazio di lavoro: (8551) "myNewWorkspace" <-> (8552) "stream19_test_max_results_1256765247692134"
Componente: (8553) "Flux Capacitor"
Baseline: (8554) 1 "Initial Baseline"
In uscita:
Serie di modifiche:
(8617) -#@ "Update from November planning meeting"
Modifiche:
-#-c /flux.capacitor/requirements.txt
In entrata:
Serie di modifiche:
(8616) -#$ "Results of initial trials"
Modifiche:
-#-c /flux.capacitor/requirements.txt
Si è verificata una collisione. I file modificati sono stati modificati anche da un altro utente che ha trasferito le modifiche al flusso. La collisione viene evidenziata dal carattere # riportato prima dei file condivisi e delle serie di modifiche condivise. Accettando la serie di modifiche con l'alias 8616, si genera un conflitto.
$ lscm accept 8616 -v -i
Repository: https://localhost:9443/jazz/
Spazio di lavoro: (8551) "myNewWorkspace"
Componente: (8553) "Flux Capacitor"
Serie di modifiche:
(8616) ADMIN -#$ "Results of initial trials"
Modifiche:
!-c /flux.capacitor/requirements.txt
Negli spazi di lavoro seguenti esistono ancora conflitti dopo l'accettazione:
myNewWorkspace
Eseguire 'scm resolve' o 'scm conflicts' o 'scm status' per tentare di risolvere i conflitti.
-i inserisce gli indicatori di conflitto nei file. Gli indicatori sono simili a quelli utilizzati da un altro sistema di controllo di origine.
Il carattere ! nell'elenco delle modifiche indica che il file ha un conflitto.
È possibile ottenere un elenco dei conflitti nei componenti correntemente caricati eseguendo il comando scm conflicts.
Il file contiene indicatori di conflitti inplace, che indicano il problema:
- Must not need any more than 1.5 gigawatts of power - Determine minimum necessary speed <<<<<<< mine - Twin Pines parking lot? ======= - Initial trials suggest 60kmh >>>>>>> proposed
La riga tra <<<<<<< mine e il segno di uguaglianza deriva dalla serie di modifiche nello spazio di lavoro. La riga tra i segni di uguaglianza e >>>>>>> proposed deriva dalla serie di modifica in entrata. È possibile ottenere il file originale eseguendo il comando lscm conflicts -m flux.capacitor/requirements.txt. Se si desidera ottenere la versione in entrata, è possibile eseguire il comando lscm conflicts -p flux.capacitor/requirements.txt. Il parametro -m è l'abbreviazione di mine mentre il parametro -p è l'abbreviazione di proposed.
Risolvere la modifica con la proposta. Rimuovere gli indicatori di conflitto dal file:
- Must not need any more than 1.5 gigawatts of power - Determine minimum necessary speed Initial trials suggest 60kmh
Eseguire il commit delle modifiche e comunicare al repository che il conflitto è stato risolto con la versione rilevata mediante il comando lscm resolve:
lscm resolve -c flux.capacitor/requirements.txt
Nessun output indica che il conflitto è stato risolto.
Il parametro -c indica che il conflitto deve essere risolto con la versione in cui è stata rilevato. È possibile utilizzare il parametro -p per risolvere il conflitto con la versione proposta.
È ora possibile effettuare nuove modifiche, trasferire la serie di modifiche con il comando lscm deliver:
$ lscm deliver Trasferimento delle modifiche da "myNewWorkspace" a "DeLorian Updates" Nessuna baseline da inserire nel flusso.
Per determinare l'autore della modifica di alcune righe di un file eseguire il comando lscm annotate:
$ lscm annotate flux.capacitor/requirements.txt 1 Marty (8556) 2009-11-04 - Must not need any more than 1.5 gigawatts of power 2 Marty (8556) 2009-11-04 - Determine minimum necessary speed 3 Doc (8616) 2009-11-04 Results of initial t - Initial trials suggest 60kmh
L'output di annotazione presenta sei colonne:
Per eseguire un confronto tra diverse versioni di un file, utilizzare il comando scm diff, che genera una patch standard.
Per eliminare le modifiche di cui non è stato eseguito il commit, utilizzare il comando scm undo.
Questa sezione descrive i comandi avanzati utilizzati principalmente dagli amministratori che configurano il controllo origine Rational Team Concert per gli altri utenti. La maggior parte degli utenti si limitano a creare e caricare gli spazi di lavoro all'interno di flussi già esistenti.
Un componente è un raggruppamento di strutture ad albero di origine che tiene uniti raggruppamenti di logiche del codice sorgente.
Al crescere del progetto, può essere necessario aggiungere occasionalmente nuove strutture ad albero sorgenti. Se non è utile per un componente esistente conservare le modifiche, è necessario aggiungere un nuovo componente:
$ lscm create component "Flux Capacitor" "DeLorian Upgrades" -r l Componente (8553) "Flux Capacitor" creato.
Nell'esempio appena riportato, è stato creato un nuovo componente all'interno del flusso DeLorian Upgrades. Gli utenti che hanno spazi di lavoro condivisi con quel flusso visualizzano l'aggiunta del componente come una modifica in entrata. Quando accettano le modifiche in arrivo, gli utenti ricevono il contenuto nel componente.
Se un utente desidera aggiungere nuovi file nel componente creato a questo scopo, potrà eseguire questa attività con il sottocomando share. Rational Team Concert consente solo la condivisione di directory e cartelle solo all'interno di uno spazio di lavoro. L'utente deve aggiungere il nuovo componente in un spazio di lavoro remoto:
$ lscm workspace add-component -r l myNewWorkspace 8553 Componente (8553) "Flux Capacitor" creato.
Nell'esempio in alto, l'alias 8553 si riferisce al componente recentemente creato dall'esempio precedente.
Il nuovo componente si trova ora all'interno dello spazio di lavoro, così che l'utente dovrà condividere (comando share) la struttura ad albero di origine all'interno dello spazio di lavoro:
$ lscm share -r l myNewWorkspace 8553 flux.capacitor Caricamento dei file in corso... Condivise correttamente
Nell'esempio in alto, questa azione carica i contenuti della directory flux.capacitor nello spazio di lavoro remoto denominato myNewWorkspace e li aggiunge nel componente specificato da 8553, ovvero Flux Capacitor della fase precedente.
Queste informazioni sono state utili? È possibile fornire un feedback su Jazz.net (è richiesta la registrazione): commenta nei forum o segnala un bug