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.