Manuale per l'uso di CVS ad Arcetri

Versione breve: per i client Unix/Linux, aggiungere nel file .cshrc*

setenv CVSROOT :ext:puglisi@obelix:/4lbt/cvs_adopt
setenv CVS_RSH ssh
setenv CVS_SERVER /bin/cvs

NB: mettere il proprio username al posto di "puglisi". Il path indicato e' quello del repository del gruppo AdOpt Il path di CVS_SERVER e' il path su Obelix e non va modificato.

Occorre assicurarsi di avere cvs installato sulla macchina locale (date il comando "cvs" e vedete se scrive qualcosa).

L'accesso via ssh comporta l'inserimento di una password ad ogni comando cvs. Chiedete a Luca Fini o Alfio Puglisi di impostarvi l'accesso ssh senza password su Obelix.

Comandi principali per usare CVS, supponendo un repository gia' in produzione:

  • accedere ad un gruppo di files:
    cvs checkout <nome_modulo>
    cd <nome_modulo>
    

  • modifica dei files
    l'editor che preferite: vi, emacs
    

  • sincronizzare la propria copia con quella sul server (da fare ogni tanto):
    cvs update
    

  • mandare al server le modifiche effettuate:
    cvs commit
    

  • fine del lavoro:
    cd ..
    cvs release _nome_modulo_
    

Versione piu' lunga:

  • La variabile d'ambiente CVSROOT deve puntare all'archivio CVS, ad esempio:
    setenv CVSROOT /usr/local/cvsroot
    

  • l'archivio CVS deve essere accessibile in lettura/scrittura a tutti gli utenti che lo useranno, quindi in genere si usa un gruppo Unix e si da' all'archivio il permesso in lettura/scrittura/esecuzione a quel gruppo. Il controllo di accesso e' realizzato per directory, non per files. Nuove sottodirectory avranno gli stessi permessi del genitore. Se i permessi vanno cambiati, occorre farlo a mano.

  • Creare l'archivio CVS:
    cvs [-d directory] init
     

  • Dare un "init" su un archivio gia' creato non cancella niente.

  • Per l'accesso client/server, viene usato per default l'rsh. Si puo' cambiare, cambiando la variabile d'ambiente CVS_RSH (mettendo per esempio ssh). In questo caso, la sintassi per specificare CVSROOT diventa:
    setenv CVSROOT :pserver:puglisi@server:/usr/local/csvroot
    
    lo stesso per le opzioni -d. L'username e' opzionale se e' uguale tra client e server:
    setenv CVSROOT :pserver:@obelix:/usr/local/cvsroot
    
    A questo punto si puo' fare un login:
      cvs [-d dir] login
    
    che verra' ricordato piu' o meno per sempre.

Il login non e' molto consigliato, perche' registra la combinazione di client host/server host/username/password, scrivendo la pa ssword in un file dentro $HOME/.cvspass, con un encoding che la documentazione definisce "trivial". Se non si fa login, l'rsh/ssh/whatever verra' ripetuto ad ogni comando cvs e la CVSROOT puo' essere messa cosi':
setenv CVSROOT :ext:username@obelix:/usr/local/cvsroot

  • Far partire l'archivio CVS:

    • importare files esistenti:
      cvs import -m "Imported sources" modulo1/sottomodulo2/sottomodulo3/nome_modulo vendor_tag release_tag
      
      importa tutti i files presenti nella directory corrente, come un modulo/sottomodulo specificato. Funziona anche per directory vuote (crea una struttura vuota di moduli/sottomoduli in CVS, pronta per essere usata)

    • importare un singolo file esistente:
      cvs add pippo.c
      cvs commit pippo.c
      
      • Se il file e' binario:
        cvs add -kb pippo.bin
        cvs commit pippo.bin
        
  • Rimuovere un file dall'archivio:
    rm pippo.c
    cvs remove pippo.c
    cvs commit pippo.c
    
o anche:
rm *.c
cvs remove .
cvs commit .
oppure:
cvs -r remove *.c
cvs commit -m "Tolgo i files inutili" *.c
  • Rimuovere la directory corrente:
    cd ..
    cvs update -P   (????)
    

Operazioni comuni con CVS:

Nota: tutti i comandi sono ricorsivi, cioe' operano sulla directory specificata e tutte le sottodirectory. Si puo' aggiungere l'opzione -l per evitare la ricorsione.

  • Estrarre un modulo per editarlo:
cvs [-d directory] checkout nome_modulo -d: ignora la variabile $CSVROOT e usa la directory speficata al suo posto nota: questo comando crea la sottodirectory "nome_modulo", che conterra' i files da editare

  • Sincronizzare un modulo tra repository e copia locale:
    cvs [-d directory] update [ nome_modulo ]
    
    L'update scarica dal repository i nuovi file, ed applica ogni modifica fatta nel frattempo da altri sviluppatori. I files aggiunti dall'utente vengono marcati come sconosciuti, e occorre eseguire un commit su di essi. Nel caso di modifiche sullo stesso file in conflitto tra di loro, l'utente e' chiamato a risolvere il conflitto.

  • Archivio di un file modificato:
    cvs commit [-m "messaggio"] pippo.c pippo2.c pippo3.c
    
    -m: commento alle modifiche. Se non presente, cvs fa partire un editor per scriverle.

  • Rilascio del modulo precedentemente estratto col checkout:
    cvs [-d] release nome_modulo
    
    -d: cancella la copia locale note: cvs avvertira' se ci sono files modificati che non sono stati archiviati con "commit"

  • definire moduli con nomi arbitrari, invece che con percorsi (alias):
    csv checkout CVSROOT/modules
    cd CVSROOT
    echo "alias_modulo percorso/fino/al/modulo/a/partire/da/$CVSROOT" >> modules  (oppure usate vi/emacs)
    cvs commit -m "Aggiunto una alias per il modulo alias_modulo" modules
    cd ..
    cvs release -d CVSROOT
    
    E' un tipico ciclo di checkout/modifica/commit/release di CVS, fatto sul file CVSROOT/modules, che contiene le definizioni dei moduli

  • vedere lo stato di un file:
    cvs status -v pippo.c
    

  • Rinominare un file:
    mv old.c new.c
    cvs remove old.c
    cvs add new.c
    cvs commit -m "Renamed old.c to new.c" old.c new.c
    
    Nota che i numeri di revisione ripartono da 1.1 per il nuovo file. Usa -r nel commit per mettere quello giusto, se necessario

  • Vedere i cambiamenti in un file:
    cvs diff pippo.c (??)
    
  • Conflitto con piu' commit contemporanei: il primo commit funziona. Il secondo da' un messaggio di errore. A questo punto, chi ha avuto l'errore da' il comando:
    cvs update pippo.c
    
    che "mescola" i due cambiamenti nella sua working copy. Se i cambiamenti erano indipendenti, finisce qui. Se invece i cambiamenti sono in conflitto, la vecchia copia di pippo.c e' salvata in .#pippo.c, e la nuova contiene ENTRAMBE le versioni, con la zona di conflitto chiaramente marcata, in modo simile all'output di un diff. L'utente deve risolvere il conflitto, e rifare un commit.

  • Numeri di revisione: i numeri di revisione vanno avanti per conto loro ad ogni modifica (e in modo diverso per ogni file). Si possono forzare:
    cvs commit -r 3.0
    
    manda tutti i files alla revisione 3.0

  • Per vedere una revisione precedente:
    cvs checkout -r 1.3 nome_modulo
    

  • Tag simbolici: I tag simbolici permettono di riunire differenti revisioni di files in un solo numero di release:

  • Assegnare un tag simbolico alla revisione:
    cvs tag rel-0-4 pippo.c
    cvs tag rel-1.4 .               (tag a tutti i files della directory)
    
    in realta' e' meglio usare:
    cvs tag -c rel-1.4 .
    
    che controlla se i files locali sono stati commit-ati, e da' un errore in caso contrario.

Comandi brevissimi:

(non c'e' bisogno di alcuna variablie di environment)

  • cvs -d :ext:lfini@obelix:/4lbt/cvs_adopt checkout -P Supervisor

  • cvs -d :ext:lfini@obelix:/4lbt/cvs_adopt update -P
Topic revision: r5 - 25 Oct 2010, LucaFini
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback