Newsgroup: it.lavoro.informatica
Titolo: [OT] E al posto di google code?

Io usavo Google Code come server SVN per tenere alcuni progetti privati.
Ora Google Code chiude. I miei progetti DEVONO rimanere privati (sono proprietà di clienti), per cui mi sa che GitHub non va bene. A occhio, BitBucket fa al caso mio. Maaa.... Alternative valide che avete provato e che potete suggerirmi?
 
-- 
Ciao e grazie
Luca


perchè dici che gitHub non va bene??
 
https://github.com/pricing
 
 
 
Ciao

 Ora Google Code chiude. I miei progetti DEVONO rimanere privati (sono proprietà di clienti), per cui mi sa che GitHub non va bene. A occhio, BitBucket fa al caso mio. Maaa.... Alternative valide che avete provato e che potete suggerirmi?
 
io uso personalmente github per i progetti pubblici, bitbucket per quelli
privati. però la roba privata sono progetti personali di media-scarsa
importanza, se fosse materiale di lavoro probabilmente opterei per github
a pagamento.

 
https://github.com/pricing
 
 
Perché a me la parte pubblica, al momento, non interessa. Ne al momento posso permettermi ${BIG_AMOUNT_OF_BUCKS} per avere un numero decente di progetti privati.

 a pagamento.
 
Magari un domani chissà... Al momento, i progetti che deposito son roba dei clienti, il cui codice alla fine finisce ai clienti, e a me serve a) un buon sistema di subversioning (e a studiare, Git batte Svn 3 a 0, per cui è ora di prendere il coraggio a due mani e migrare) e b) un deposito per questioni storiche,

 Ora Google Code chiude. I miei progetti DEVONO rimanere privati (sono proprietà di clienti), per cui mi sa che GitHub non va bene. A occhio, BitBucket fa al caso mio. Maaa.... Alternative valide che avete provato e che potete suggerirmi?
 
Io ho attivato un server SVN (ma poteva essere anche Git) sul mio NAS 
QNAP. Posso accederci sia da Ufficio (dove ho ovviamente il NAS) sia da 
Casa (tramite VPN).
 
Se non avete un NAS, basta anche un vecchio PC su cui installare Ubuntu 
Server (o altro sistema Linux).
 
 
-- 
Daniele Pinna
DAPINNA.COM
 
(leva oops per rispondere)
-----
Utente Skype: dapinna
DAPINNA.COM
        :  
http://www.dapinna.com
 
Il Docfa in Pillole:  
http://www.ildocfainpillole.it
 - Sito Aggiornato!!!
DAPINNA.COM
 su Facebook: 
https://www.facebook.com/dapinnadotcom
 
BLOG: 
http://storielaboratorioinformatica.wordpress.com
 


ma deve poter essere accessibile ovunque? L'alternativa potrebbe essere il 
cloud de noartri. 
Ti compri un NAS e sul volume che esporti ci installi git o il sistema di 
versioning che più ti piace. 
Se vuoi qualcosa un po' guificato puoi installare la community edition di 
gitlab, e così ha una interfaccia in perfetto stile github. 
 
 
-- 
Massimiliano Adamo

Il Fri, 13 Mar 2015 17:02:20 +0000, Max_Adamo ha scritto:
 
ah... gitlab offre i repo privati: 
https://about.gitlab.com/gitlab-com/
 
 
-- 
Massimiliano Adamo

 Server (o altro sistema Linux).
 
anche io gli ho dato lo stesso suggerimento... ma quanto vale un bel "git 
init" dentro una directory di dropbox? 
 
non hai nemmeno bisogno di clonare e fare il push remoto... ti basta un 
commit sul master locale nella cartella di dropbox ;) 
 
 
-- 
Massimiliano Adamo


git init dentro una cartella di dropbox o di google drive e passa la 
paura ;) 
non devi nemmeno fare il push e clone perché lavori direttamente sul 
master. 
 
 
-- 
Massimiliano Adamo


 
Bamboo + Stash + Nexus ?
 
M.

 Server (o altro sistema Linux).
 
piuttosto che un vecchio pc meglio un raspberry, consuma un decimo e git
via ssh lo esegue tranquillamente.
 
però sinceramente con tutte le risorse che ci sono online e per di più
gratuite tenere i sorgenti in casa mi sembra cercarsi inutilmente dei
guai. 

 commit sul master locale nella cartella di dropbox ;) 
 
è il modo garantito di fare presto o tardi del casino.
 
la volta che committi offline da due postazioni diverse vedrai che gioia 
quando dropbox ti sincronizza i repository. te lo dico perché ci ho
provato.
 


mmh .... hai ragione anche tu. 
Lo scenario è che stai lavorando mentre dropbox è offline per una qualche 
ragione. 
A questo punto si potrebbe creare una copia locale di git, da un git 
remoto che sta sullo stesso filesystem: 
git clone /bla/bla 
 
Anche questo non va benissimo... devi ricordarti di non fare push prima di 
aver aggiornato dropbox. 
 
E' una soluzione che non va bene 
 
Ma io ho scoperto adesso che il mio Nas Western Digital ha tra le varie app 
installabili proprio git ;) 
 
 
Quindi facciamo un discorso serio: perché Torvalds ha ideato git? Per 
consentire di poter lavorare meglio su copie locali (evitando tutti i 
problemi noti di cvs e svn). Pertanto tu lavori sulla tua copia locale e 
quando torni in casa, o quando torni in ufficio fai "git push". 
Poi, se hai paura che il tuo nas possa prendere fuoco, scheduli una copia 
del tuo git che tieni sul nas su un cloud online. 
Questo mi pare che vada meglio. 
 
-- 
Massimiliano Adamo


guarda male che va lo usi con lo stesso workflow di svn. fra qualche mese,
anche senza studiare, ti renderai conto che quello di svn non è lavorare.

 guarda male che va lo usi con lo stesso workflow di svn.
 
Se si č abituati a subversion il passaggio a mercurial č piů semplice, 
IMHO. I nomi dei comandi sono sovrapposti o comunque simili.
 
 
-- 
Andrea
 

 anche senza studiare, ti renderai conto che quello di svn non è lavorare.
 
Nono, io sono per i tagli netti. Se inizio a usare GIT, uso GIT (fornito da GitHub o da altri) come deve essere usato GIT.
 
PS. e così chiudiamo. Aperto account BitBucket, già creato il repository locale e caricato il primo progetto. Si integra in Eclipse che è una bellezza.
 
-- 
Ciao!
Luca


io preferisco non gestirlo da eclipse.
 
ti consiglio questo (free for non-commercial use):
http://www.syntevo.com/smartgit/
 
poi inizia da qui per un workflow efficiente:
http://nvie.com/posts/a-successful-git-branching-model/
 
(lo strumento che ti ho suggerito lo integra nativamente).
 

 IMHO. I nomi dei comandi sono sovrapposti o comunque simili.
 
 
io uso git e stavo leggendo adesso le differenze tra git e mercurial... 
"gli utenti git sono più rabbiosi e fanno i missionari porta a porta" e 
questo mi ha costretto a dover diventare più buono. 
 
Ma scherzi a parte, io credo potrebbe essere più conveniente imparare a 
parlare la lingua di git, che oggi è una lingua molto più diffusa. 
 
-- 
Massimiliano Adamo

 Questo mi pare che vada meglio. 
 
mi chiedo per quale ragione passare dalla nas, quando uno può fare le 
push direttamente sul servizio online e può farle subito con una 
qualsiasi connessione ad internet.

 (lo strumento che ti ho suggerito lo integra nativamente).
 
Qui sono arrivato prima io (nel senso che l'ho già letto)! ;)
 
-- 
Ciao!
Luca
 

 qualsiasi connessione ad internet.
 
Perché non tutti - soprattutto quelli che sono andati a sbirciare i 
selfie rubati di Jennifer Lawrence - si fidano dei servizi online e sono 
molto "gelosi" del proprio codice sorgente.
Lo dico anche per esperienza personale.
 
Ora che l'azienda per cui lavoravo che la pensava così è stata acquisita 
da una multinazionale americana le cose son cambiate... ad esempio la 
posta non sta più dentro quella merda di Microzozz-qualcosa (prima era 
Lotus 123 fantecavalloere, mi pare), ma ce l'ha Google. Con pace 
all'anima di quelli che hanno paura dello spionaggio industriale.


Se ho capito bene il branching-model proposto, non e' altro che un modo 
(ben organizzato) di utilizzare git, o no?
In tal caso, la rete di sviluppatori dovrebbe uniformarsi a tale stile, 
ma non vedo come non possano accadere dei casini se omettono di 
utilizzare il modello in modo pedissequo. Mi figuro grosso modo analoghi 
conflitti che accadono con svn e cvs. Nel senso che i comandi git in se 
non prevedono un modello particolare, quindi se viene utilizzata una 
naming-convention difforme, i casini posso essere anche distruttivi.
Correggimi se sbaglio.


I motivi possono essere molteplici. Sicurezza a parte, GitHub inc. dice 
che se ti cancelli l'account (anche per errore) perdi per sempre tutti i 
contenuti collegati. Se lo fai in casa, mal che vada puoi sempre 
ricorrere ai back-up.

 conflitti che accadono con svn e cvs. 
 
manco per idea. 
 
-- 
Massimiliano Adamo

 qualsiasi connessione ad internet.
 
privacy? Il backup sul cloud potrebbe essere uno snapshot criptato che 
invi a periodi regolari. 
 
-- 
Massimiliano Adamo


E non solo backup. Tutte le aziende di cloud dicono sempre "non possiamo 
accedere ai tuoi dati", ma non è vero. Un nostro cliente ha fatto espressa 
richiesta di non volere nemmeno un bit su amazon. 
Non so perché con noi si sentono tutelati e con loro no :) Forse vogliono 
evitare che vengano frammentate ulteriormente le responsabilità sulla 
riservatezza dei dati, forse, in caso di controversia è più difficile 
confrontarsi con una azienda del calibro di amazon. Forse che alcuni fatti 
recenti hanno messo la pulce nell'orecchio di tanti. 
 
-- 
Massimiliano Adamo


dipende anche quanto vale il tuo segreto industriale e da quale nazione 
proviene la tua azienda. 
un conto è se rubano il codice di rootkit per il calcolo delle distanze 
nel magazzino. Lavoro sicuramente pregevole, ma un altro conto è se ti 
rubano i progetti per il nuovo motore che consuma 1 litro di benzina ogni 
200 km. 
L'altro giorno il mio capo è stato a far visita ad azienda $xxx. Appena 
entrato gli hanno messo uno stick sulla fotocamera del cellulare e gli 
hanno detto "non ci provare nemmeno". Sempre azienda $xxx ha detto 
chiaramente: "i nostri server da Amazon non ce li mettete in alcun caso". 
Gli scenari possibili sono molteplici ed inimmaginabili! 
Si può andare dal consulente/dipendente che ruba i dati, alla NSA che fa 
spionaggio, ad una azienda che paga per esfiltrare i tuoi dati, ad uno 
scenario di crisi tra stati. 
Amazon per esempio, può dire quel che vuole. Hanno troppe clausole sui 
loro brevetti e la gente che lavora li dentro ha la mano destra che non sa 
cosa fa la mano sinistra. 
 
-- 
Massimiliano Adamo

 hanno detto "non ci provare nemmeno". 
 
ci mancava la benda negli occhi prima di portarlo nel covo :) Mi ha 
raccontato che erano quasi a quei livelli. 
 
 
-- 
Massimiliano Adamo

 Lo dico anche per esperienza personale.
 
non so quale sia questa esperienza personale, ma io rispondevo a chi parlava
di avere il repository su una nas in casa e il backup sul cloud. al che
mi chiedo per quale motivo uno dovrebbe farsi scrupoli per avere il 
repository online e non per i backup.
 
per inciso anche nell'azienda dove lavoro abbiamo una installazione 
di gitlab interna e accessibile via vpn, mi sembra anche giusto, ma
non stiamo parlando di questo. luca sta scegliendo un sostituto di
google code per i suoi progetti personali non decidere la politica di
una azienda.
 
 

 gitlab interna e accessibile via vpn, 
 
ottima scelta. Gitlab senza se e senza ma! 
Noi siamo passati da SVN a gitolite, per poi finire su gitlab integrato 
con LDAP (e possibilità di usarlo con chiavi ssh). La granularità dei 
permessi è da paura, non di meno il fatto che si fa tutto in "self 
provisioning": ti crei il repo da solo e dai i permessi ai colleghi. 
 
Con gitolite usavamo i submodule per raggiungere lo stesso obiettivo. Ma 
sono un po' noiosi. 
 
-- 
Massimiliano Adamo

 ricorrere ai back-up.
 
beh non so se hai provato a cancellare un repository su github; se si può
cancellare un account per sbaglio allora si può anche cancellare 
la casella postale per sbaglio, o fare un bonifico per sbaglio. secondo me
siamo al di sotto del livello di attenzione minimo necessario per non avere
una vita flagellata dai guai :-)


Certamente, ma cosi' come non puoi chiedere ad uno stupido di essere 
intelligente, non puoi neanche chiedere di non fare errori ad un essere 
fallibile per sua natura.
La mia considerazione era solo per far presente che in casa puoi 
adottare delle politiche per proteggerti da fatti infausti, se GitHub 
inc. non lo fa e lo scrive sulla sua licenza che accetti, hai di fatto 
accettato di lavorare senza rete.
Se poi lo strumento e' git, sicuramente molto potente ma dalla sintassi 
parecchio complessa, va da se che stai espandendo le probabilita' che un 
errore possa essere commesso.
Solo per questo motivo ritengo che la necessita' di operare in un 
ambiente protetto sia auspicabile. Al di la' della presunzione di 
infallibilita'.

 accettato di lavorare senza rete. 
 
hai perfettamente ragione. In casa hai i backup mentre github è gratuito e 
ci manca anche che ti fornisce pure i backup. 
Tuttavia... parliamo di sistemi di versioning decentralizzati. Pertanto 
avrai copie locali ovunque e il versioning ti protegge intrinsecamente 
contro cancellazioni accidentali. 
se invece hai cancellato l'account e qualsasi copia locale disponibile... 
beh solo a lourdes potrai trovare protezione adeguata. 
 
 
-- 
Massimiliano Adamo

 errore possa essere commesso.
 
ammesso che sia così, fatico davvero tanto a trovare un errore che non sia 
facilmente rimediabile. 

 Correggimi se sbaglio.
 
allora... andiamo per ordine.
chiariamo: se uno vuole fare casino il modo lo trova e non c'è strumento
che tenga. io parlo di quello che offre lo strumento e delle tecniche,
se uno fa a modo suo e bypassa l'uso di tutte le features che aiutano
a risolvere i conflitti è chiaro si rimette nelle stesse condizioni.
 
ciò premesso, quello che è poco chiaro a chi lavora con i vecchi strumenti
è che questi workflow sono pratici, non burocratici. su svn l'idea di
fare un branch per ogni modifica fa accapponare la pelle ma su git è una
pratica che in termini di impegno costa zero. in altre parole il rischio
che per pigrizia la gente non ti segua è sostanzialmente inesistente. 
 
poi volendo puoi anche forzare la cosa, basta impedire agli utenti di
fare i push sui branch di develop e di release. dipende quanto snello
vuoi rendere il modo di lavorare del gruppo.

 200 km. 
 
si però ragazzi, stay focused.
si stava parlando di una persona che ha dei progetti personali su google
code e vuole spostarli perché chiudono. non di dove la verisign dovrebbe
salvare la sua chiave ca privata.
 
ps: nel fare lo spiritoso hai pure cannato l'esempio: nel caso in questione
di codice da rubare ce n'è veramente poco e se eri stato attento ci 
saresti arrivato anche da te.

 sia facilmente rimediabile.
 
L'unico modo per procurare un danno assolutamente irreversibile è: 
1. cancellare tutto e fare commit.
2. eseguire un truncate dell'history e fare commit.
 
ma basta cercare su google "git truncate history" per rendersi conto che è 
una cosa che non può accadere né per caso, né per errore. 
 
-- 
Massimiliano Adamo


ma lascia perdere ... scusa se ho nominato il tuo nome invano. Non 
intendevo in alcun modo accostarmi ai suoi ranghi, ne altresì era mio 
scopo sminuire la sua preminentissima figura :) 
 
-- 
Massimiliano Adamo

 che tenga. 
 
da noi, su 4 repository, nel solo branch di test, abbiamo accumulato la 
bellezza di 34082 (34mila) commit e - mi disse un collega - prima che 
venissi io fu fatto per qualche ragione un truncate dell'history (*). 
problemi visti ad oggi: poco più di ZERO ... 
 
in realtà, l'unico problema serio che afflige qualsiasi sistema di 
versioning (tutti inclusi) è quando qualcuno inserisce, anche per errore, 
dei file binari di grosse dimensioni, quel file (anche se cancellato) te 
lo porterai sul groppone fino alla fine dei giorni. Questa è l'unica 
occasione in cui puoi meditare un truncate. 
 
-- 
Massimiliano Adamo

 una cosa che non può accadere né per caso, né per errore. 
 
in realtà non è neanche detto che saresti riuscito a fare qualcosa di
irreparabile.
git è distribuito, la history distrutta la si può sempre ricostruire
da un qualsiasi altro programmatore.

 Curiosità mia: perché?
 
io ho 4 editor diversi con GIT integrato in 4 modi diversi tra loro: sublime la vuola cotta, brackets la vuole cruda, eclipse e netbean la vogliono scotta ... e io alla fine lo uso al 99% da riga di comando. 
 
Quel tool 'smartgit' non e' malaccio comunque. 


bravo... giusto. 
e non solo... mi pare, mi sembra, che quando distruggi l'history un pull non e' 
piu' sufficiente. 
Mo' francamente non lo so bebe cosa bisogna fare, perche' non sono cose che si
fanno tutti i giorni ma sicuramente troverai in giro qualcuno che sta ancora 
smadonnando perche' - fortunatamente - non gli funziona il 'pull' :) 
 

 Curiosità mia: perché?
 
perché come strumento grafico quello che ho indicato è molto meglio, mentre
le operazioni di routine preferisco la linea di comando. l'unica cosa per
cui ho il plugin git di eclipse è che mi fa vedere mentre lavoro su che
branch mi trovo.


un tool grafico comunque lo ritengo indispensabile. più che altro perché
una volta presa confidenza con lo strumento diventano di routine 
operazioni relativamente avanzate come applicare singole commit da un
branch ad un altro, e in questo uno strumento che fa navigare rapidamente
nella storia e da una visione d'inseme è utilissimo.

 rapidamente
 
mmhhh: git cherry-pick <hash_del_commit>
alla fin fine non c'è bisogno di un mostro in java... però sono d'accordo 
che è meglio usare un tool esterno all'editor, non perché sia migliore o 
peggiore, ma perché quando cambi editor, il tool non cambia ;) 
 
-- 
Massimiliano Adamo

 mmhhh: git cherry-pick <hash_del_commit> 
 
 
poi si possono fare anche altre zozzate: 
 
se sei in acceptance e vuoi fare il merge da test di una sola directory: 
git checkout test -- .
 
se invece vuoi un file specifico:
git show test:./miofile.txt > miofile.txt
 
comunque è talmente complesso che in genere lo usiamo come il nostro 
cervello, al 10% delle sue potenzialità :) 
 
-- 
Massimiliano Adamo