
mirko@mirko-laptop:~/Fud$ ./fudconf
Questo script configurerà Fud tramite domande interattive. Per maggiori informazioni, consultare la documentazione di Fud o fare riferimento al file di esempio fud.sample-conf.
Configurare Fud? (Y/n): Y
Scegli il metodo da utilizzare per la sincronizzazione.
[1] ssh
[2] ftp
Metodo: 2
Selezionato il metodo ftp.
Server per la connessione: ftp.myserver.com
Utente per la connessione: myuser
Per eseguire la connessione al server, potrebbe essere necessaria una password. Tuttavia, questa opzione non è obbligatoria, perché l'utente indicato potrebbe non avere una password oppure perché si è deciso di utilizzare ssh con un certificato, ad esempio. Nel caso non sia necessario indicare una password, lasciare in bianco questa opzione
Password per la connessione: mypwd
Porta per la connessione: 21
Indicare una directory locale da sincronizzare. Se questa directory non esiste, verrà creata.
Directory locale da sincronizzare: [/home/mirko/Fud] /home/mirko/myownbackups
Creata la directory /home/mirko/myownbackups
Indicare una directory remota per la sincronizzazione. Se questa directory non verrà indicata, verrà stabilita dal server.
Directory remota per la sincronizzazione: /backup
Se lo si desidera, si possono specificare delle opzioni aggiuntive per Unison, oltre a quelle già utilizzate da Fud. Consultare `man unison` per maggiori informazioni. Se non si sa cosa si sta facendo, lasciare vuota questa opzione
Opzioni aggiuntive per Unison:
Vuoi che Fud venga lanciato automaticamente all'avvio? (Y/n): Y
Successo: Fud è stato correttamente configurato ed è pronto per essere utilizzato. Buona sincronizzazione!
mirko@mirko-laptop:~/Fud$ cat ~/.fud/fud.conf
METHOD="ftp"
SERVER="ftp.myserver.com"
USER="myuser"
PWD="mypwd"
PORT="21"
LPATH="/home/mirko/myownbackups"
RPATH="/backup"
EXTRAOPTIONS=""
Indicare una directory remota per la sincronizzazione. Se questa directory non verrà indicata, verrà stabilita dal server.
# Gnome
if [ ! -e "~/.config/autostart" ]; then
#Crea il file ~/.config/autostart/fud.desktop
echo -e "\n[Desktop Entry]\nName=Fud\nGenericName=File Synchronizer\nComment[en_GB]=Sync your files\nComment[it]=Sincronizza i tuoi file\nExec=fud\nTerminal=false\nType=Application\nIcon=fud\nHidden=false\nCategories=Network;FileTransfer;\nStartupNotify=false" > ~/.config/autostart/fud.desktop
fi
$ git clone git://github.com/mirkop88/Fud.git
# ./Fud/install
$ fudconf
$ fud
pmate ha scritto:Ho creato un account anch'io su github e ho provveduto al fork del tuo repository (come spiegato in questa pagina). In questo modo mi sarà più semplice "tenermi aggiornato" sugli sviluppi e provvedere a qualche esperimento di mio.
pmate ha scritto:Tutto ciò posso aggiungerlo io allo script senza nessun problema e proporti il diff.
pmate ha scritto:Una sola considerazione: visto che il fine è quello di facilitare le cose all'utente finale, credo sia cosa buona prevedere anche la presenza di un eventuale proxy. Insomma, fare in modo che lo script di configurazione possa (se necessario) fare l'export di http_proxy (e di eventuali parametri di autenticazione).
sconosciuto ha scritto:Per quanto riguarda l'autostart dovrebbe andare bene per tutti i DE: http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html#startup. Posso dirti comunque che su KDE funziona (non ho provato tutto lo script, ma ho eseguito il comando che crea il file fud.desktop cambiando la voce Exec=fud).
mirko.pagliai ha scritto:In altri termini, non ho ancora capito come estendere le funzionalità di git ad altre persone. Mi preme anche poter creare a breve un nuovo ramo, onde evitare di apportare continuamente cambiamenti ad un unico ramo e rendere lo script pressoché inutilizzabile per chi è interessato solo a provarlo.
$ cd Fud
$ git branch nuovoramo
$ git checkout nuovoramo
$ git commit -m "testo di esempio"
$ git push origin nuovoramo
$ git checkout master
Per ora ti ho aggiunto tra i collaboratori, dal menù admin, ma non sono un granché sicuro che funzioni così :-D
Non ci avevo proprio pensato. Ma proprio per niente... sarà che non uso e non ho mai usato un proxy.
Accetto di buon grado :-D E colgo l'occasione per estendere nuovamente l'invito a tutti.
pmate ha scritto:Per aggiungere un nuovo ramo (ad esempio... "nuovoramo"): [...]
pmate ha scritto:mirko.pagliai ha scritto:Per ora ti ho aggiunto tra i collaboratori, dal menù admin, ma non sono un granché sicuro che funzioni così :-D
Funziona così (grazie di avermi inserito) tanto che posso uploadare le modifiche direttamente sul tuo master.
Però credo sia meglio come ho fatto fino adesso: tengo il fork del tuo master e ho creato un trunk. In quest'ultimo faccio le modifiche e ti propongo una pull request in modo tale che tu possa valutare la proposta, testare se vuoi e poi decidere se applicare al ramo principale oppure no.
Credo sia meno invasivo così.
mirko.pagliai ha scritto:E secondo te, quanti e quali rami possono essere adatti per sviluppare tranquillamente uno script del genere (cioè non troppo lungo e complesso, dal punto di vista del codice)?
Io avevo pensato di creare almeno un ramo "stable" (o presunto tale), dove il codice si può grossomodo assumere come tale, e un ramo "di sviluppo", soggetto a cambiamenti anche continui (e quindi di scarso interesse per chi vuole subito utilizzare lo script).
mirko.pagliai ha scritto:pmate ha scritto:Per aggiungere un nuovo ramo (ad esempio... "nuovoramo"): [...]
E secondo te, quanti e quali rami possono essere adatti per sviluppare tranquillamente uno script del genere (cioè non troppo lungo e complesso, dal punto di vista del codice)?
Mi sto anche studiando un po' Git (per chi fosse interessato, ho trovato questa splendida ed esaustiva guida.
Stemby ha scritto:Più che i rami master (trunk) e sviluppo (branch) come nel vecchio SVN, visto che con Git la gestione delle branche è uno dei suoi punti cardini, ti consiglio di aprire un nuovo ramo per ogni singolo "argomento". Mi spiego con un esempio: vuoi aggiungere la gestione del proxy? Crei un ramo "proxy". Poi quando hai finito il lavoro e tutto è testato a dovere, merge in master e seghi via il ramo proxy. Questo può avvenire anche dopo aver aperto altri rami: i merge di solito vanno lisci (Git è davvero efficientissimo in questo).
mirko.pagliai ha scritto:Un ramo stabile, uno di sviluppo, sotto-rami di sviluppo per argomento! :-D
Stemby ha scritto:Più che i rami master (trunk) e sviluppo (branch) come nel vecchio SVN, visto che con Git la gestione delle branche è uno dei suoi punti cardini, ti consiglio di aprire un nuovo ramo per ogni singolo "argomento". Mi spiego con un esempio: vuoi aggiungere la gestione del proxy? Crei un ramo "proxy". Poi quando hai finito il lavoro e tutto è testato a dovere, merge in master e seghi via il ramo proxy. Questo può avvenire anche dopo aver aperto altri rami: i merge di solito vanno lisci (Git è davvero efficientissimo in questo).
Visitano il forum: Nessuno e 1 ospite