Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: python sera gestion-sourcé par mercurial

0 views
Skip to first unread message

Mihamina Rakotomandimby (R12y)

unread,
Apr 2, 2009, 3:43:21 AM4/2/09
to
[suivi sur fr.comp.developpement]
William Dode wrote:
>>> - bzr est trop lent et (du coup) son format change trop rapidement
>>> (oblige à avoir une version à jour, pas celle de debian-lenny par ex)
>> Je pensais Bazaar plus aboutit que ça.
> A part ce problème de perf,

Je ne comprend pas non plus cette recherche de perf lors du commit: apres
un commit on peut bien lever les yeux quelques secondes de l'écran pour
voir le temps qu'il fait dehors, ou regarder l'heure qu'il est, etc...

De plus, ces histoires de offline, ça ne tient debout que si le developpeur
est sur une connexion internet rapide.

Imaginez un peu la douleur d'un developpeur qui est sur une connexion lente
et qui doit télécharger le code (ça, c'est inevitable) + son historique...

Encolpe Degoute

unread,
Apr 2, 2009, 2:18:19 PM4/2/09
to
Mihamina Rakotomandimby (R12y) a écrit :

> [suivi sur fr.comp.developpement]
> William Dode wrote:
>>>> - bzr est trop lent et (du coup) son format change trop rapidement
>>>> (oblige à avoir une version à jour, pas celle de debian-lenny par ex)
>>> Je pensais Bazaar plus aboutit que ça.
>> A part ce problème de perf,
>
> Je ne comprend pas non plus cette recherche de perf lors du commit:
> apres un commit on peut bien lever les yeux quelques secondes de l'écran
> pour voir le temps qu'il fait dehors, ou regarder l'heure qu'il est, etc...

Voire quelques minutes...
Je me souviens de pull interminable avec darcs : Au bout de deux heures
je finissais par couper la mise à synchronisation et de merger à la main
le code.

> De plus, ces histoires de offline, ça ne tient debout que si le
> developpeur est sur une connexion internet rapide.

C'est vrai que les connexions GSM/3G sont super rapides...
Le principe est d'uploader la code dans un cybercafé en Thaïlande par
exemple, puis de bosser offline le temps du voyage.

> Imaginez un peu la douleur d'un developpeur qui est sur une connexion
> lente et qui doit télécharger le code (ça, c'est inevitable) + son
> historique...

Cybercafé ou clé USB d'un autre développeur.

--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales

William Dode

unread,
Apr 3, 2009, 6:06:56 AM4/3/09
to
On 02-04-2009, Encolpe Degoute wrote:
> Mihamina Rakotomandimby (R12y) a écrit :
>> [suivi sur fr.comp.developpement]
>> William Dode wrote:
>>>>> - bzr est trop lent et (du coup) son format change trop rapidement
>>>>> (oblige à avoir une version à jour, pas celle de debian-lenny par ex)
>>>> Je pensais Bazaar plus aboutit que ça.
>>> A part ce problème de perf,
>>
>> Je ne comprend pas non plus cette recherche de perf lors du commit:
>> apres un commit on peut bien lever les yeux quelques secondes de l'écran
>> pour voir le temps qu'il fait dehors, ou regarder l'heure qu'il est, etc...
>
> Voire quelques minutes...
> Je me souviens de pull interminable avec darcs : Au bout de deux heures
> je finissais par couper la mise à synchronisation et de merger à la main
> le code.

Pour ma part, je bosse plutôt sur des petits projets, c'est plus le
"lag" de départ qui me fatigue.
L'intérêt d'un outil décentralisé c'est justement que l'on peut faire
des commits, des logs etc instantanément car tout est en local. Et du
coup instantanément ou quelques secondes ça change tout. Sur les
opérations en ligne le lag est encore pire entre bzr et hg.

>
>> De plus, ces histoires de offline, ça ne tient debout que si le
>> developpeur est sur une connexion internet rapide.

Au contraire puisque justement on peut travailler sans même dépendre
d'une connexion !

>
> C'est vrai que les connexions GSM/3G sont super rapides...
> Le principe est d'uploader la code dans un cybercafé en Thaïlande par
> exemple, puis de bosser offline le temps du voyage.
>
>> Imaginez un peu la douleur d'un developpeur qui est sur une connexion
>> lente et qui doit télécharger le code (ça, c'est inevitable) + son
>> historique...

Encore une fois, il aura d'autant plus intérêt à tout télécharger une
seule fois et ne plus dépendre de sa connexion par la suite s'il a une
connexion lente...

Pour info, sur le dépôt python par ex, le temps de récup initial n'est
pas énormément différent malgré le téléchargement de l'historique.

svn : 50s
hg : 2m15

Évidement, tout dépend de ce qu'il va faire après, plus il va travailler
dessus, faire des clones etc plus il bénéficiera de son dépôt local.

>
> Cybercafé ou clé USB d'un autre développeur.
>

Oui, c'est toute une organisation différente, on ne peux pas comparer
sans en tenir compte... Surtout que l'on peut très bien partir d'un
dépôt ancien.

--
William Dodé - http://flibuste.net
Informaticien Indépendant

Mihamina Rakotomandimby (R12y)

unread,
Apr 7, 2009, 8:10:19 AM4/7/09
to
William Dode wrote:
> Oui, c'est toute une organisation différente, on ne peux pas comparer
> sans en tenir compte... Surtout que l'on peut très bien partir d'un
> dépôt ancien.

Et l'historique des autres aussi, on le télécharge pas?
Ce qui ferait que l'historique est à mon avis sur-dupliqué.
Sauf bien sur si je n'ai pas bien compris comment ça fonctionne.

William Dode

unread,
Apr 17, 2009, 8:02:51 AM4/17/09
to
On 07-04-2009, Mihamina Rakotomandimby (R12y) wrote:
> William Dode wrote:
>> Oui, c'est toute une organisation différente, on ne peux pas comparer
>> sans en tenir compte... Surtout que l'on peut très bien partir d'un
>> dépôt ancien.
>
> Et l'historique des autres aussi, on le télécharge pas?
> Ce qui ferait que l'historique est à mon avis sur-dupliqué.

C'est un des avantages, il y a autant de backups que de gens qui
clonent.

0 new messages