M9k/gist:92f93752b07299dff4a1532437c76644

## 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.