M9k · January 30, 2018 22:07
diff --git a/gistfile1.txt b/gistfile1.txt
 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 ^/branches/XYZ da trunk per portare le modifiche effettuate sul trunk
 -OPPURE- (e più usato)
 svn merge ^/tags/XYZ-start ^/tags/XYZ-end (dove i tags sono stati creati prima di iniziare a lavorare a XYZ e alla fine dei lavori)
 se da un branch voglio aggiornare all'ultima versione del trunk prima di fare un merge per verificare le ultime modifiche uso
 (dal branch)
 svn merge ^/trunk
 verifico, se tutto ok allora merge
 (nel trunk)
 svn merge ^/branches/XYZ --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 cambiano "verso"

 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 il commit (supponendo di essere nel trunk e che sia stato fatto nel trunk) che ha portato alla revisione 10:
 svn merge -r10:9 ^/trunk . (applica al contrario le modifiche dalla revisione 9 alla 10, quindi le annulla)
 --------------------------------------------------------------------------------------------------------
 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
 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.
	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 ^/branches/XYZ da trunk per portare le modifiche effettuate sul trunk
	-OPPURE- (e più usato)
	svn merge ^/tags/XYZ-start ^/tags/XYZ-end (dove i tags sono stati creati prima di iniziare a lavorare a XYZ e alla fine dei lavori)
	se da un branch voglio aggiornare all'ultima versione del trunk prima di fare un merge per verificare le ultime modifiche uso
	(dal branch)
	svn merge ^/trunk
	verifico, se tutto ok allora merge
	(nel trunk)
	svn merge ^/branches/XYZ --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 cambiano "verso"

	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 il commit (supponendo di essere nel trunk e che sia stato fatto nel trunk) che ha portato alla revisione 10:
	svn merge -r10:9 ^/trunk . (applica al contrario le modifiche dalla revisione 9 alla 10, quindi le annulla)
	--------------------------------------------------------------------------------------------------------
	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
	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.