svn cat file svn cat url/file stampa a video il file indicato del BASE! Cioè la versione presente sulla repo anche nel caso sia stato modificato. Utile da usare con pipe e redirezioni, ad esempio svn cat file > file per ripristinare un file (uguale a svn revert) svn ls url/path visualizza il contenuto di una path di una repo svn svn info path/file/url visualizza informazioni svn info, cat e url possono avere -r REVISIONE per visualizzare le informazioni di una data revisione -------------------------------------------------------------------------------------------------------- In file config di subversion (quello di impostazioni del client locale, non del server) # diff-cmd = diff_program (diff, gdiff, etc.) # diff-extensions = -u -p Il primo serve a usare un programma esterno di diff, il secondo per specificare parametri extra, ad esempio ignorare gli spazi # global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo __pycache__ # *.rej *~ #*# .#* .*.swp .DS_Store [Tt]humbs.db I file verranno sempre ignorati, uguale a .gitignore, ma per qualsiasi working directory autoprops si possono specificare i metadata/mime per i file, così svn riesce a capire se sono binari o di testo si possono indicare anche quali caporiga usare (ad esempio CRLF per Windows) -------------------------------------------------------------------------------------------------------- Changelist svn non ha la funzione di add di git, tutti i file sono inviati al primo commit, ma si potrebbero aver fatto due modifiche e volerle mandare separatamente, oppure una subito e l'altra in futuro. Per risolvere si usano changelist, cioè insiemi di file ragruppati e inviabili un gruppo per volta ATTENZIONE! Si ragruppano a file, non a modifiche, se un file appartiene a due modifiche diverse... fregati. per creare un gruppo: svn changelist NOMECHANGELIST FILEDAAGGIUNGERE per committarla: svn commit -m "asdasd" --changelist NOMECHANGELIST la changelist è presente solo in locale (gli altri utenti non la vedono) ed una volta effettuato il commit verrà rimossa non ha specificato a lezione come aggiungere altri file, basta guardare la documentazione -------------------------------------------------------------------------------------------------------- ripetuto il comando export per prelevare i file da una repo senza creare una working copy -------------------------------------------------------------------------------------------------------- OPERATIVE REVISION / PEGVERSION Situazione: creo un file X alla revisione 1, alla r3 lo elimino, alla r5 lo ricreo, arrivo alla r7 il comando "svn cat -r2 X" stamperà "il file X non esisteva alla revisione 2" Questo perchè il file X precedente ed il successivo NON sono lo stesso file, pur avendo lo stesso nome, vengono identificati dalla PEGVERSION Di default la pegversion dei file indicati è quella della revisione corrente, si indica con @, quindi svn cat -r2 X era implicitamente svn cat -r2 X@7 riassumendo: X@7 = X@6 = X@5 X@4 non esiste X@3 = X@2 = X@1 X@6 -r5 è valido, indica la versione della revisione 5 del file X "tracciato" nella revisione 6 X@5 -r6 è ancora valido, ma più insolito, può essere utile a controllare se un file è stato rimosso e ricreato nel tempo Il sistema di controllo della validità è basato su alberi che si diramano se una revisione duplica un file ad esempio nella revisione 6 X è stato copiato in Y Y@6 -r5 stamperà il Y nella revisione X, cioè X@5 -r5 r5 r6 ___ Y X __/ \___ X -------------------------------------------------------------------------------------------------------- svn log stampa gli ultimi commit -lNUMERO stampa gli ultimi NUMERO commit -v verbose, indica anche quali file sono stati modificati -r x:y dalla revisione x alla revisione y -r x nella revisione x --stop-on-copy stampa i commit fino a quando la cartella/file è stata creata mediante duplicazione, utile per i branch, altrimenti un file copiato mostra i commit che ha avuto anche precedentemente alla copia svn diff stampa il cambiamento in un file o directory --summarize indica solo i file modificati -c 10 indica solo i cambiamenti nel commit 10, è equivalente a -r9:10 svn url1 url2 mostra le differenze tra due repo, o tra due catelle delle repo NOTA: ricordarsi che ^ è sinonimo dell'url corrente della repo, utile per abbreviare gli url -------------------------------------------------------------------------------------------------------- Conflitti su file: già affrontati Conflitti su cartelle: Io faccio una modifica a X/file, nel frattempo qualcuno rinomina X in Y, quando faccio svn co up un errore: A + C X M X/file X non è presente nella repo, andrebbe aggiunta, ma c'è un conflitto perché esiste in realtà ma è spostata M è il file modificato il locale, non più presente in remoto Soluzioni: cancello Y, risolvendo il conflitto oppure sposto X/file in Y/file, elimino X Problema: Y/file potrebbe avere modifiche da integrare con X/file Soluzione: uso "patch", strumento Unix/Linux (Su Windows si può installare con Cygwin) cd X svn diff > ../patchfile cd .. cd Y patch ../patchfile (applica le modifiche rilevate su X/file in Y/file, se conflitti risolvo al solito modo) poi elimino patchfile e X, risolto -------------------------------------------------------------------------------------------------------- Branches struttura di default di un progetto: -branches: rami di sviluppo -tags: milestone o "segnalibri", che NON devono essere modificati -trunk: ramo di lavoro corrente, il master di git Attenzione! la struttura è una convenzione usata, non è obbligatorio fare in questo modo (nulla mi vieta di modificare tags) per creare branch o tags uso cp, nessun comando particolare comando svn merge ^/trunk da un branch per mettere le modifiche sul trunk se dal trunk voglio aggiornare un branch prima di fare un merge per verificare le ultime modifiche uso (nel trunk) svn merge ^/branches/funzionalità-XYS verifico, tutto ok, merge (nel branch) svn merge ^/trunk --reintegrate reintegrate serve a dirgli di ignorare tutte le modifiche apportate dal merge precedente dal trunk al branch Attenzione! effettuabile 1 volta per branch, dopo genera conflitti Da un branch a un altro posso fare qualsiasi numero di merge, finchè sono nella stessa direzione I problemi ci sono solo se le modifiche passano da uno all'altro comando merge: svn merge VERSIONEBASE VERSIONEMODIFICATA DESTINAZIONEDELLEMODIFICHERILEVATE usabile anche come svn merge -r4:6 ^/branches/ASD (copia da dove sono ora le modifiche dalla revisione 4 alla 6 e applicale in ASD) trick per rimuovere un commit: svn merge -r10:9 ^/trunk . (non ho ben capito i parametri in questo caso, devo riguardare la documentazione) prende le differenze tra la versione 10 e la 9 e le applica, praticamente l'opposto del commit 10 -------------------------------------------------------------------------------------------------------- svn switch permette di passare da un url all'altro senza rimuovere e ricreare la working copy, come git MA può far cambiare un url solo a una directory o un file! (in teoria si fa anche con git, non so come) ES: sviluppo X che usa libreria Y, la libreria Y la voglio sempre prelevare dal svn di Y, non voglio copiarla e aggiornarla cd X cd Y svn switch URL-Y --ignore-ancestry (senza questo ignore mi segnala un errore perché sto cambiando un url solo a una porzione della working copy, che è rara come operazione) svn st -> ai documenti switchati mostra una S Trick inutile: In una cartella di una repo si più settare come url la sua root, duplicando i file TRANNE la cartella stessa, altrimenti sarebbe un loop infinito, ogni modifica nella cartella viene fatta alla root e il contrario. Non serve a nulla.