Il giorno 21/set/2011, alle ore 18:24, Enrico Franchi ha scritto:
> Giovanni:
>> A costo di essere noioso lo ribadisco: non so se GIT sia complesso
>> e Mercurial sia una bicicletta, da noi uno ha funzionato e l'altro no.
>
> E questo e' proprio interessante, invece. Nota a margine, io uso piu'
Andrea Francia wrote:
Quando ho scritto che è meno complicato intendevo che:
- un versioning centralizzato è più facile da spiegare a persone che
non ne sanno poco o niente di VCS
E di questo non ne sono esattamente convinto. In particolare, la mia
impressione e' che, anche ammettendo che l
Enrico Franchi wrote:
> Esatto. Poi voglio dire... lo spazio; i nostri favoriti si tirano
> dietro tutto il repo, quindi li vince comunque svn. Sempre se la
> memoria non mi inganna. Credo che siano anni che non lo uso.
Non mi risulta che Subversion supporti gli shared repository. Una cosa
simile,
Francesco Maida wrote:
Non mi risulta che Subversion supporti gli shared repository. Una cosa
simile, ma non funzionalmente identica, si ottiene usando svn:externals.
Non parlavo di shared repositories. Mi limitavo a dire che i distribuiti
per funzionare ti portano tutto il repo sul disco, men
Il giorno gio, 22/09/2011 alle 10.37 +0200, Nicola Larosa ha scritto:
> Enrico Franchi wrote:
> > Esatto. Poi voglio dire... lo spazio; i nostri favoriti si tirano
> > dietro tutto il repo, quindi li vince comunque svn. Sempre se la
> > memoria non mi inganna. Credo che siano anni che non lo uso.
>
On Wed, Sep 21, 2011 at 04:26:03PM +0200, Vittorio Zuccala' wrote:
> Tra Git, Mercurial e Subversion quale è il più immediato e completo da
> usare?
un paio di punti che non mi sembrano che siano venuti fuori:
+1 mercurial, scritto in (c-)python, gli hook possono essere scritti come
funzioni
Marco Giusti wrote:
+1 mercurial, scritto in (c-)python, gli hook possono essere scritti come
funzioni python e visto il tema di questa mailing-list è un punto a suo
favore
Questo e' effettivamente un grossissimo vantaggio. Sinceramente ho
sempre amato l'idea di aggiungere hooks per almeno al
On Thu, Sep 22, 2011 at 03:50:09PM +0200, Enrico Franchi wrote:
> Marco Giusti wrote:
>
> >+1 mercurial, scritto in (c-)python, gli hook possono essere scritti come
> >funzioni python e visto il tema di questa mailing-list è un punto a suo
> >favore
>
> Questo e' effettivamente un grossissimo van
On Wednesday, September 21, 2011 04:50:58 PM lordkrandel wrote:
> Non ho letto bene, ma provate a dare un occhiata qua
> http://www.ossblog.it/post/8155/un-plugin-aggiunge-il-supporto-a-git-su-
dolphin
Letto, cosi` come ho letto che ci sara` anche il plugin per mercurial :)
Enrico
__
On Wednesday, September 21, 2011 04:26:03 PM Vittorio Zuccala' wrote:
> Tra Git, Mercurial e Subversion quale è il più immediato e completo da
> usare?
Questa discussione e` a livello di editor vs ide, gui vs web e tanti altri
flame che si stanziano attorno al mondo del software utilizzato d
On Wednesday, September 21, 2011 06:31:18 PM Enrico Franchi wrote:
> La 1. non e' assolutamente "facile" rispetto ad un git init
$ svnadmin create /path/del/repository
$ svn co /path/del/repository
:)
Il problema di SVN, semmai, e` che lo sharing del progetto ti costringe a
mettere su un serve
PythonCad e sotto Git
OpenErpPLM e' sotto Git
che dire +2 per git :-)))
ciao,
Matteo
Il 22/09/2011 20:27, Enrico 'Henryx' Bianchi ha scritto:
On Wednesday, September 21, 2011 06:31:18 PM Enrico Franchi wrote:
La 1. non e' assolutamente "facile" rispetto ad u
On Thursday, September 22, 2011 03:50:09 PM Enrico Franchi wrote:
> In realta' no... Perforce, peccato per la sua commercialita', ma per
> essere un centralizzato e' fatto davvero bene.
Beh, il problema non e` l'essere centralizzato, ma come e` strutturato CVS e,
conseguentemente SVN (una su tu
Io credo che non sia una questione di git/mercurial/SVN qual è il migliore
ma di poter utilizzare quale di questi ci si trova comodi.
Io personalmente ho usato Mercurial e mi sono trovato bene, con SVN al
lavoro ho avuto qualche problema ma nulla di che, magari se imparassi ad
usare git lo trovere
14 matches
Mail list logo
