La semaine passée, à un jour d’intervalle, deux petites nouvelles concernant l’actuel chouchou des gestionnaires de version, à savoir Git, sont passées un peu inaperçues. Ce dernier vient de sortir, le 21 octobre, en version 1.8.0, et Gitlab, application Web d’autogestion de projets sous Git, passe, lui, en version 3.0 depuis le 22 octobre.
Les nouveautés de ces deux logiciels sont un peu plus détaillées dans la seconde partie de la dépêche.
Git 1.8.0
Cette nouvelle version de Git, gestionnaire de version sous licence GPL v2 apporte un nombre conséquent de corrections de bogues et de nouveautés à tous les niveaux, de l’interface graphique à l’envoi de courriels, en passant par la performance. Si vous voulez la liste exhaustive, référez‐vous aux notes de version. En synthèse, on peut noter :
- ajout de Windows (Win 32) et GNOME Keyring, pour l’aide à l’identification — credential helpers — ;
- améliorations et ajouts dans l’interface graphique ;
- nouvelles options pour les sous‐commandes
cherry-pick,difftool,grep,log,rebaseet le daemongit; - concernant la gestion des courriels,
git amnettoie le sujet d’un message etgit send-emaildemande une confirmation si l’adresse du destinataire n’est visiblement pas une adresse de courriel ; git svnest maintenant compatible avec Subversion 1.7 ;- le portage sur le système d’exploitation de HP NonStop.
Le mainteneur de Git, Junio C. Hamano, a aussi annoncé que la prochaine version 1.9._x_, verrait un changement de comportement de la commande push. Celle‐ci ne devrait plus permettre d’« écraser » accidentellement une branche sur un serveur distant. De plus, la commande git branch --set-upstream a été marquée comme obsolète — deprecated — et ne devrait plus exister sous peu. Elle peut être remplacée avantageusement par git branch [-u | --set-upstream-to], qui propose un arrangement des arguments plus « sensé ».
Gitlab 3.0
Basé sur Ruby on Rails et Gitolite, Gitlab est une application Web sous licence MIT qui permet d’héberger et de gérer soi‐même ses projets « versionnés » avec Git. Une sorte de clone du très connu Github. Plus de 300 commits sont annoncés depuis la précédente version. Les changements se situent à la fois côté utilisateur et sous le capot, dont voici une rapide synthèse.
Côté utilisateur
- amélioration de la navigation dans les fichiers ;
- mise à jour de l’interface de programmation, avec plus de fonctions exposées ;
- présence d’un éditeur Web ;
- prise en charge des groupes de projets.
Sous le capot
- prise en charge non officielle de PostgreSQL ;
- augmentation significative des performances concernant les commits ;
- réorganisation et nettoyage de code ;
- correction d'un bogue critique lors de la suppression ou de l’ajout de clefs SSH.
Capture d’écran du tableau de bord de Gitlab
Alternatives
Parmi les alternatives libres à Gitlab et proposant comme lui Git, notons Indefero, dont l’auteur, Loïc d’Anterroches vient nous entretenir souvent ici, mais aussi Gitorious, sous AGPL, ou encore le toujours plus libre GNU Savannah, sous GPL v2+. Parmi les non‐libres, citons le difficilement contournable Github, l’outsider Bitbucket, l’ogre Google code et le vénérable SourceForge. Sur le Wikipédia anglophone, vous trouverez une page de comparaison presque exhaustive !
Aller plus loin
- Notes de version Git 1.8.0 (369 clics)
- Site Web officiel de Git (214 clics)
- Annonce de Gitlab 3.0 (300 clics)
- Site Web officiel de Gitlab (432 clics)
- Site de démonstration de Gitlab (338 clics)
# Utilisateurs de Gitlab ?
Posté par Maxime (site web personnel) . Évalué à 10.
Je viens de voir que le code source de Gitlab était hébergé sur… Github. C'est dommage de ne pas respecter le principe du "Eating your own dog food", mais j'en viens à me demander : qui utilise Gitlab ?
[^] # Re: Utilisateurs de Gitlab ?
Posté par kyusan . Évalué à 1.
ça me choque pas, ils peuvent quitter GitHub quand ils le souhaitent. Et pour l'usage c'est bien pratique pour les développements non ouverts au publique comme on utilise Redmine, Trac et autres.
[^] # Re: Utilisateurs de Gitlab ?
Posté par Maxime (site web personnel) . Évalué à 10.
L'intérêt du dogfooding est double : d'une part en tant qu'utilisateur du produit, tu vois directement ce qu'il faut améliorer et tu expériences directement les bugs. Et d'autre part, ça montre aux potentiels utilisateurs que c'est un produit au moins aussi bon que la concurrence.
Là, je vois qu'il s'agit d'un clone de github et je me dis qu'il n'est certainement pas au niveau de github puisqu'ils ne l'utilisent même pas.
[^] # Re: Utilisateurs de Gitlab ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Tu fais l'expérience des bugs, ou tu subis les bugs, comme tu voudras, mais « expériencer », c'est un verbe qui n'existe pas en français.
[^] # Re: Utilisateurs de Gitlab ?
Posté par El Titi . Évalué à 9.
C'est du JCVD. T'es vraiment pas aware comme type.
http://www.echolaliste.com/x28.htm
[^] # Re: Utilisateurs de Gitlab ?
Posté par El Titi . Évalué à 9.
" J'adore le chien. Tu bois une biere et tu en as marre du gout. Alors tu manges du chien. Le chien c'est doux et salé, fort et tendre,comme une femme. Manger des chien, it's a really strong feeling. Et apres tu as de nouveau envie de boire de la bière. Le chien c'est le mouvement perpétuel à la portée de l'homme ".
[^] # Re: Utilisateurs de Gitlab ?
Posté par Thom (site web personnel) . Évalué à 3.
github et gitlab ne fonctionnent pas exactement de la même manière. github héberge sur le web ton dépôt (+social) alors que gitlab te propose une interface similaire à installer sur ta propre machine.
Je pense que l'intérêt est là.
Pour le public, open-source, on reste sur github qui a pour avantage d'être tourné vers le social. Mais dans le cas d'un dépôt privé, d'une part on paie et d'autre part on n'a pas besoin du social, car justement le but est de ne pas laisser son code transparaitre. Donc, dans le cas d'un dépôt privé, ça peut devenir intéressant de gérer ce genre d'outils.
L'autre cas, qui ressemble pourrait être celui d'un intranet d'une petite startup.
Plus simplement, installé en local sur ton ordi si tu veux du code compatible git mais que tu es un peu frileux de tout faire en ligne de commande et que tu aimes ce genre d'outils (mon cas). Comme ça, si comme moi tu as une mémoire tampon, on peut très bien imaginer que tu y mets des fichiers de configs sensible que tu commentes et suit dans le temps.
Un cas con dans lequel ça pourrait être utile, ça serait dans l'enseignement. Le prof au lieu de donner et ramasser des tp à l'arrache crée une instance gitlab et demande à ses élèves de se créer un compte et de publier leur tp dessus. En plus, ça les formerait un peu à comprendre que la partie rédaction est importante dans un projet.
Personnellement, j'utilise github pour mes petits projets et autres codes, mais je trouve que c'est une très bonne idée et comme je suis un peu entrain de restructuré mon ordi et mon serveur, j'avoue que je m'intéresse de près à ce genre d'outils.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: Utilisateurs de Gitlab ?
Posté par Maxime (site web personnel) . Évalué à 10.
Je ne remets absolument pas en question l'intérêt de ce logiciel ! C'est très bien, je me réjouis de voir ce genre de logiciel (actuellement j'utilise du redmine pour un besoin similaire qui me permet d'avoir des dépôts git et svn).
Ce que je reproche c'est juste qu'ils ne l'utilisent même pas eux. Alors oui, y'a le côté social de GitHub, mais c'est tout. Mais ils perdent tous les bienfaits du dogfooding sur la crédibilité et le retour d'expérience.
[^] # Re: Utilisateurs de Gitlab ?
Posté par cypX . Évalué à 1.
Oui l'interêt de Gitlab, c'est l'aspect privé (et éventuellement local), d'ailleurs il me semble que par défaut il n'y a pas d'accès anonyme à l'interface (à vérifier).
Github propose aussi des dépôts privés mais contre un abonnement.
C'est la solution que j'ai choisis au boulot et connecté en LDAP (sur une AD…) pour la gestion des comptes utilisateur ça remplis parfaitement son rôle.
Le petit plus par rapport aux alternative c'est l'interface agréable et que tout le monde connait puisqu'elle
copies'inspire de Github.Il y aussi le système de ticket qui n'est pas présent sur toutes les solutions concurrentes (Gitorious par exemple)
[^] # Re: Utilisateurs de Gitlab ?
Posté par isildur37 . Évalué à 2.
Bitbucket permet d'avoir des repos privés avec du social (mais limité en contributeurs) et des repos public sans limite de contributeurs.
Ce projet a un intérêt certain, mais reste très en retrait de GitHub et Bitbucket (j'ai testé les 3). D'autant plus qu'il nécessite d'être couplé à un mécanisme de sauvegarde et un minimum de sécurisation côté serveur, afin de garantir suffisamment le code…
Pour moi, ses places de prédilection sont :
_ hébergé sur sa propre machine
_ sur un serveur d'entreprise
Par contre, sur un serveur perso (hébergé ou à la maison), c'est un peu plus compliqué à mettre en œuvre.
[^] # Re: Utilisateurs de Gitlab ?
Posté par fredoche . Évalué à 4.
Dans une certaine mesure, c'est pas très important. Du jour au lendemain, le dépôt de référence peut très bien devenir celui de gitlab, et de la même façon, les contributions pourront aussi bien arriver via github, et ensuite être reversées sur le dépôt de référence, c'est le principe même de la décentralisation. Dans la mesure où le projet est jeune et éventuellement instable, il est peut être prudent de ne pas mettre des bâtons dans les roues des éventuels premiers contributeurs, et les faire participer via la plateforme de référence en attendant.
[^] # Re: Utilisateurs de Gitlab ?
Posté par Oles . Évalué à 1.
Aussi, ils peuvent commencer par utiliser Github puis passer à Gitlab quand leur produit est plus mature (mais là ça a déjà l'air assez mature donc c'est étrange).
"Never trust a statistic you haven't faked yourself."
[^] # Re: Utilisateurs de Gitlab ?
Posté par El Titi . Évalué à 6.
Une tentative d'explication.
GitLab est un projet pour déployer sa propre plateforme mais les membres n'ont peut-être pas envie d'en administrer une publique. Il s n'ont peut-être pas l'ambition de faire du business avec.
A la différence de Gitorious ou In defero par exemple qui fournissent une forge et un hébergement.
Ca expliquerait pourquoi ils ne sont pas listés ici
http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities
mais ils devraient l'être ici par contre:
http://en.wikipedia.org/wiki/Forge_(software)
[^] # Re: Utilisateurs de Gitlab ?
Posté par Bruno Michel (site web personnel) . Évalué à 10.
En fait, c'est l'inverse. Le code de gitlab était hébergé sur une instance lors des toutes premières versions de gitlab (les 0.x). Mais gitlab est fait pour des projets privés et non pas des projets Open-Source. Du coup, quand ils ont commencé à avoir des contributions externes, ça a posé problème et les créateurs de Gitlab ont donc décidé de passer leur code sur github pour favoriser les contributions externes.
[^] # Re: Utilisateurs de Gitlab ?
Posté par Oles . Évalué à 3.
Pourquoi se limiter à des projets privés ? C'est dommage de leur part.
Le problème c'est que, même avec une instance publique, les contributeurs devront passer l'étape d'inscription avant de contribuer alors que sur Github ils peuvent contribuer tout de suite.
"Never trust a statistic you haven't faked yourself."
[^] # Re: Utilisateurs de Gitlab ?
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 4.
En plus de toutes les raisons citées précédemment, il peuvent aussi vouloir s'inspirer fortement de ce que fait GitHub. À ce titre, il est certainement plus pratique d'utiliser GitHub afin de mieux connaître ce que l'on souhaite reproduire.
# Qu'est-ce qu'utilisent les plus gros projets ?
Posté par feth . Évalué à 6.
Il est frappant de voir que les plus gros projets (Linux ou Xorg par exemple) n'utilisent pas les forges web, mais seulement gitweb et des pull request par mail (git request-pull).
Pourquoi, à votre avis ?
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par El Titi . Évalué à 6. Dernière modification le 30 octobre 2012 à 17:59.
Parce que les premiers codent le noyau et n'ont pas d'environnement graphique, que GitHub n'est pas accessible en mode texte et que les seconds utilisent une version en dev de cet environnement qui ne fonctionne pas, que GitHub n'est toujours pas accessible en mode texte.
C'est le principe du "dogfooding"
J'ai juste ?
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par feth . Évalué à 10. Dernière modification le 30 octobre 2012 à 18:06.
Github est accessible en mode texte pour l'essentiel depuis peu : https://gist.github.com/3342247
Linus Torvalds a dit tout le mal qu'il pensait de la façon dont github pervertit la notion de pull request :
https://github.com/torvalds/linux/pull/17#issuecomment-5654674
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par El Titi . Évalué à 4.
Très intéressant !
J'imaginais même pas qu'il puisse y avoir une réponse sérieuse à ma remarque.
Sinon pour ceux qui ne savent pas comme moi ce qu'est exactement un "pull request"
http://git-scm.com/book/fr/Git-distribu%C3%A9-Contribution-%C3%A0-un-projet
http://www.kernel.org/pub/software/scm/git/docs/git-request-pull.html
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par feth . Évalué à 2. Dernière modification le 30 octobre 2012 à 18:21.
Suivi de
…
…
…
…
…
je cite donc Benjamin Herrenschmidt dans son mail :
ad lib, je pense qu'on a compris :)
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par El Titi . Évalué à 3.
pure crap
it's crap absolutely WILL happen".
ad lib, je pense qu'on a compris :)
Ad crapitum me parait plus judicieux
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par ckyl . Évalué à 3.
Et il pense vraiment qu'en échangeant github par git request-pull qui demandent exactement les mêmes informations et produisent la même chose (sous une présentation différente) ça changerait quelque chose au contenu ?
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par feth . Évalué à 5.
Il me semble, à lire le fil de discussion, que Linus Torvalds est confronté à un problème que la plupart des projets libres n'ont pas : trop de contributions à gérer.
En conséquence, il met en place un genre de filtre passe haut, en refusant d'examiner les contributions qui ne sont pas de grande valeur, avec notamment le critère de la qualité de la présentation des commits : un corps de moins de 72 caractères de large, décrivant complètement le patch (parfois vingt lignes pour un patch d'une seule, dit-il) et une ligne de résumé de moins de 50 caractères séparée du corps.
En l'espèce, Torvalds chante les louanges de github en tant qu'hébergeur, mais reproche à cette plateforme 1) de ne pas permettre facilement de saisir des messages de commit propres et, 2) si j'ai bien compris, de déplacer vers ses pages de discussion certaines informations qui seraient mieux rangées dans un message de commit (mais pas nécessairement toutes, vu que pour le noyau, les mailing lists servent également à discuter de patches en dehors des messages de commit).
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par ckyl . Évalué à 4.
Bha oui on est d'accord ce n'est clairement pas un problème d'outil. Si tu fais les choses proprement avec l'un des outils tu le feras proprement avec un autre. Je ne vois aucune différence. Et c'est bien le sens de ma remarque.
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par feth . Évalué à 5.
Oui, d'accord là-dessus. Linus Torvalds reproche à github de ne pas avoir donné suite à ses remarques. Enfin, reproche, c'est un grand mot, ils font ce qu'ils veulent, et lui, il se sert de github uniquement pour publier.
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par Littleboy . Évalué à 2.
Ils ne visent tout simplement pas la meme categorie d'utilisateurs (et c'est tres bien comme ca). En l'etat il semble possible de faire des pull requests sur github qui soit dans le format souhaite par Linus, mais ca ne force pas la main de l'utilisateur.
Le projet libre auquel je participe est sur Github et on utilise/accepte les pull requests. Si ca nous obligeait aux meme criteres que pour les patchs que recoit Linus, on aurait a peu pres 0 contributeurs externes (et je ne parle meme pas d'avoir la meme attitude que la lkml, les utilisateurs etant bizarrement peu receptifs a l'excuse "j'ai tellement d'emails et de boulot a gerer que je dois me comporter comme un gros connard pour y arriver").
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par 16aR . Évalué à 2.
D'ailleurs, pourquoi git ne reformatte-t-il pas automatiquement les messages de commits pour que ca rentre dans les paramètres ? Si c'est tellement mal vu et si c'est tellement dérangeant, pourquoi ne pas forcer la main en reformattant automatiquement lors du commit ?
Ca ne pas doit être bien compliqué, surtout si on ne prend pas en compte les traits d'unions etc…
Personnellement, je trouve que github est une des meilleures choses qui soit arrivée aux projets libres depuis git. Depuis que y'a github et gitorious, j'ai participé a des projets même pour ne corriger qu'une faute de typographie d'1 lettre. Chose que je n'aurai jamais fait si j'avais a sortir un patch par mail, m'inscrire à la mailing list etc. Et pourtant, ca fait un faute en moins dans un README, c'est toujours ca de travail de relecture en moins pour le developpeur principal qui a surement d'autre chose à faire que vérifier toutes les typos dans les README/commentaires ou autre.
[^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?
Posté par claudex . Évalué à 3.
On peut imaginer que la plupart des gens codant Linux ou Xorg bossent avec leurs outils (qu'ils ont développé pour certains) et qu'ils sont donc bien plus productif avec. Contrairement à beaucoup d'autres projets bien plus jeune avec des contributeurs moins expérimentés avec ces outils.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Gitlab recommend at least 1Gb ram
Posté par Nasga . Évalué à 4. Dernière modification le 30 octobre 2012 à 18:03.
Bon, je découvre gitlab, ça me semble un bon moyen de pousser toute l'équipe à utiliser git.
Le projet semble très bon, intéressant mais sur la procédure d'installation, je lis :
Pourquoi ?
J'ai eu des problèmes similaires avec redmine, et je trouve qu'il nécessite également énormément de ram par rapport aux services rendus.
Bientôt un raspberry ne sera bon qu'a afficher l'heure si on continu à ce train là.
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Kioob (site web personnel) . Évalué à 9. Dernière modification le 30 octobre 2012 à 18:06.
On est pas vendredi, mais c'est marqué, et c'est la même raison que pour Redmine : «Gitlab 3.0 : Basé sur Ruby on Rails»
Oui bon ça va, je sors
alf.life
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par El Titi . Évalué à 2. Dernière modification le 30 octobre 2012 à 18:18.
J'avais pas osé.
La solution est donc d'utiliser JRuby. C'est ce qu'on avait fait pour Redmine sur un PC Windows et ca tenait très bien la charge pour 10 personnes.
Du coup tu n'a plus besoin d'1 Go mais de 2 comme ça.
Plus sérieusement c'est quoi cette manie de se plaindre sans arrêt pour de la RAM.
Ici aussi http://linuxfr.org/nodes/96205/comments/1404127
Et chez nous on a un gros projet qui réclame une JVM à 4 Go pour tourner en prod et ca fait un énorme pataquès.
Ca coûte quoi 1Go de Ram aujourd'hui ?
Les sysadmins touchent des primes à l'octet économisé ou quoi ?
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Anonyme . Évalué à 9.
Ce n'est pas un question de cout mais une question d'optimisation de l'utilisation des ressources.
Pourquoi imposer 1Go de RAM et 4 CPUs pour faire tourner un service web quand on peut le penser intelligemment pour qu'il n'utilise que 512Mo et 1 CPU sur une machine dont la consommation sera moindre ?
Pour le même prix, tu pourras mettre en place un serveur supplémentaire pour faire de la répartition de charge et un serveur pour gérer tes sauvegardes.
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Kioob (site web personnel) . Évalué à 6.
Malheureusement comme me répondent certains clients : «parce qu'un serveur avec XXGo de RAM ça coûte rien, contrairement au salaire d'un dev» (typiquement 64Go à moins de 150€/mois chez un célèbre hébergeur français).
Bref, le temps c'est de l'argent, alors que la RAM vaut de moins en moins.
Perso je serais d'avis d'essayer de bien penser le truc dès le départ, mais bon…
alf.life
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par niconoe . Évalué à 3.
Oui, enfin ça dépend quoi…
Ici, il y a quand même le choix au départ d'embarquer Ruby et Rails comme dépendance. A partir de là, même en "pensant bien le truc" tu as un environnement pas mal lourd. Mais ça t'apporte quand même pas mal d'avantages par rapport à une approche plus bas niveau.
Perso je choisis pas les mêmes outils et je code pas pareil si je dois faire une webapp avec webservices ou si je dois écrire un bout de code qui doit tourner sur Arduino. Et clairement ici quand je vois la description du projet, le choix des outils ne me parait pas insensé. Après rien ne t'empêche de faire la même chose avec des scripts CGI en assembleur, mais ce serait pas mon choix non plus.
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par feth . Évalué à 2.
Plutôt FastCGI : tu vas quand même pas forker et relire les données à chaque requête !
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par barmic . Évalué à 4.
Je suis tout à fait d'accord. Les gens ont tendance à voir 2 qualités logiciel : la correction et la performance. Il y a en un tas d'autres qui peuvent être plus importants que la performance (parce que pour la correction c'est tout de même important). La maintenabilité, la facilité d'écriture en fonction des compétences que l'on a, la facilité à faire des tests, la sécurité, du temps que l'on a a y consacrer,… Tout les projets n'ont pas pour finalité d'être installable sur une montre qui consomme 0,6 Watt a pleine charge.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par groumly . Évalué à -7.
optimiser juste pour la beaute du geste, ca sert pas a grand chose.
Sur, tu peux faire tourner ton machin dans 64Mo de ram sur un 386, mais ca va te couter un bras en dev, tout ca pour tourner au final virtualise sur un octo coeur avec 64Go qui passe au final son temps a branler le mammouth.
Et c'est pas delirant non plus de faire des recommandation qui partent du principe qu'il peut y avoir des pics de charges ponctuels, et donc prevoient en consequence.
Soit t'as une equipe d'ops dediee qui va allouer une VM sur un gros machin qui est de toutes facons la, soit tu fais ca a la rache sur un desktop planque sous ton bureau, et je parie une couille qu'il a un core2duo avec 2Go de ram mini.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par karteum59 . Évalué à 2.
Sur beaucoup de machines modernes (le raspberry pie était donné en exemple), la RAM est soudée, fixe et non extensible. Sur des machines un peu moins modernes, la RAM est limitée par le chipset (par exemple 3 Go sur les machines à base de 945GM, pas si ancien que ça), et pourtant elles devraient pouvoir continuer à rendre les mêmes services qu'autrefois.
Je comprends le raisonnement disant que le salaire d'un dev coûte plus cher que le hardware (ceci parce qu'on ne paye pas l'énergie ni les matières premières à leur vrai prix : on ne paye que l'effort nécessaire à leur extraction, mais rien correspondant à la ressource elle-même, qui est finie et non renouvelable). Mais à la fin on n'a qu'une planète => sans aller jusqu'à dire qu'il faut tout coder en assembleur, ce serait bien que les devs fassent un petit peu attention aux ressources qu'ils consomment pour éviter de nous faire changer de machine tout le temps ! Un raspberry pie avec 256 Mo de RAM devrait pouvoir être largement suffisant pour ce genre d'usage serveur ! (c'est quand même moins contraint qu'un C64 ! :)
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par barmic . Évalué à 6.
Tu ne trouve pas ça triste comme évolution ? On crie au loup quand Apple crée des téléphones avec une batterie non-amovible mais il est loin d'être le seul. Avoir la mémoire soudée c'est aussi devoir tout changer quand celle-ci est morte ou quand on veut gagner un peu en mémoire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 2.
La batterie non-amovible fait a priori partie d'une stratégie d'obsolescence programmée chez Apple et ce depuis le début avec les batteries d'iPod programmées pour durer 18 mois (Apple a du mettre en place un système de remplacement suite à un procès), jusque récemment avec le nouveau connecteur de l'iPhone 5.
Du côté du Raspberry, je pense personnellement que c'est loin d'être fait dans un contexte stratégique de programmer l'obsolescence, mais plus d'économie de coûts et de place, car rajouter un connecteur amovible, mine de rien ca a un impact sur ces deux points. Pour moi, si ta RAM meurt trop tôt, tu fais fonctionner la garantie et si la quantité de RAM ne te convient pas, il y a d'autres solutions. Et ce n'est pas comme si on ne pouvait plus rien faire tourner de nos jours avec 512 Mo. Il y a toujours plein de distros Linux taillées pour ce type de matériel. Alors que chez Apple, plus de batterie => poubelle et anciens câbles => poubelle. Les autres constructeurs ont démontré que l'on pouvait faire aussi bien, voire mieux, que les produits de la pomme, avec une batterie amovible, un connecteur standard, etc.
Bref, tu ne cherches pas des poux sur la bonne tête.
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Prosper . Évalué à 0.
La batterie non-amovible fait a priori partie d'une stratégie d'obsolescence programmée[…]chez Apple, plus de batterie => poubelle
L'obsolescence programmée n'a pas lieu d'être puisque tu peux faire changer ta batterie sur les produits apple.
http://support.apple.com/kb/index?page=servicefaq&geo=France&product=iphone&select=BATTERY_REPLACEMENT#top
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 10.
Merci donc à Elizabeth Pritzker, car sinon, cela n'aurait pas été le cas. Il a fallu qu'Apple se prenne un procès pour qu'il le fasse. Ça faisait donc partie de leur stratégie initiale, qui a été contrée dans ce cas précis.
Je cite le lien donné en exemple pour ceux qui n'ont pas cliqué :
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par LeMagicien Garcimore . Évalué à 2.
Et pourquoi chez Apple ce serait obligatoirement de l'obsolescence programmée ? Eux aussi (surtout eux en fait) ils doivent faire des économies de d'espace et d'argent. Le nouveau connecteur c'est justement un exemple d’économie d'espace. Ils ont quand même gardé le même format plus de 10 ans, à l’époque le micro USB n'existait même pas. (après est-ce qu'ils devraient plutot utiliser de l'USB, c'est un autre débat).
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 5.
Comme je le disais, les autres constructeurs y arrivent très bien. Notamment pour la batterie amovible. Quant au connecteur, c'est plutôt, je pense, de l'obsolescence par incompatibilité pour une histoire de gros sous et de brevets, rendant obsolète plutôt les accessoires que le téléphone lui-même. Je ne suis pas sûr que sur certains périphériques, l'adaptateur puisse être utilisé (place physique, maintien stable de l'appareil, notamment dans les voitures, etc.)
Côté argent, c'est vrai que leur situation est vraiment précaire. Plus grosse capitalisation boursière, ils ont aussi la plus grosse réserve de cash.
Faux (source). C'est à partir de 2003 que le connecteur 30 broches est arrivé sur des iPod de 3e génération. Avant c'était du firewire. Ça fait donc moins de 10 ans.
Ben non, il n'est pas réversible (ce qui est, avouons-le franchement, une véritable révolution).
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par barmic . Évalué à 3.
Ça fait 9 ans c'est tout de même pas mal je trouve (moi qui n'aime pas Apple).
C'est à dire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par 2PetitsVerres . Évalué à 8.
Le connecteur est dans le groupe cyclique C_2. (on peut le tourner de 180° et ça marche toujours) C'est deux fois mieux qu'un connecteur usb, mais toujours infiniment moins bien qu'un connecteur coaxial.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par windu.2b . Évalué à 9. Dernière modification le 01 novembre 2012 à 17:16.
C'est à dire que tu peux le brancher dans les 2 sens, ce que ne permet pas l'USB (qui a un détrompeur).
Et il faut bien admettre que c'est pratique. Qui n'a jamais râlé contre l'USB et ses 3 sens (" pas dans ce sens-ci… ni dans celui-là… Ah ben le premier était le bon, en fait ! ") ?
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par groumly . Évalué à -7.
Super, et la concurrence a change combien de fois de connectique entre temps?
Vu le nombre de chargeurs divers et varies qui trainent dans mes tiroirs, je dirais une fois tous les 2 a 3 ans au mieux, soit environ 4 a 5 changements
Deja explique ici meme: trouve le moyen de faire passer tout ce que fait passer le dock d'apple (audio in/out, video, controle a distance et j'en oublie probablement), sans avoir besoin d'un CPU dedie juste pour faire hote USB avec un protocole dédie, et on en reparle.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Juke (site web personnel) . Évalué à 6.
la connectique a changé 3 fois en 16 ans sur mes telephone nokia, avec à chaque fois des adaptateurs fournis avec les téléphones gerants toutes les anciennes connectiques.
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Nasga . Évalué à 1.
Je veux bien venir chercher le matériel que tu jettes pour un défaut de batterie et tes anciens câble ;)
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par groumly . Évalué à -5.
Pour les cables, tu pousses un peu quand meme. Ya qq dizaines de millions d'imachins avec l'ancien dock, les gens les gardent.
Pour la batterie, la question est combien de temps la batterie tient elle? Mon ipod video a rendu l'ame apres 6 ans de loyaux services, et c'est pas la batterie qui m'a lache mais le disque dur (je suis deja surpris qu'il ait dure aussi longtemps vu ce qu'il a prit).
Le laptop de madame, 2 ans au compteur, tiens ses 6 heures sur batteries, ce qui est pas si loin de 7 initialement annoncee, apres plus d'une centaine de cycles.
Ben voyons. Les autres constructeurs qui changent leur format de batterie tous les 6 mois, arretant de produire l'ancien qui donc double ou triple de prix d'un coup?
Les memes qui changeaient tellement souvent de connectique pour les chargeurs qu'il a fallu pondre une loi au niveau europeen pour les forcer a arreter?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Nasga . Évalué à 4.
Je suis développeur, pas sysadmin et justement avec mon architecture de cluster à 2 node, si j'attribue 1Go d'un coté, je doit conserver 1Go de libre de l'autre coté, soit un cout de 2Go.
De plus le "At least" me fait peur…
Mon serveur svn actuel dispose de 64mo de ram pour info…
Mais sinon, oui on a pleins de ram/pétrole/uranium/espace disque/whatever alors pourquoi se priver ?
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Pour info, on peut faire tourner une instance de gitlab sur une Raspberry Pi avec 512Mo de RAM. Un collègue a testé et ça tournait très bien.
Sinon, Ruby est plutôt gourmand en RAM et Rails est une grosse base de code. Actuellement, les serveurs applicatifs fonctionnent avec plusieurs processus et comme Ruby n'est pas encore Copy on write friendly, ça peut vite faire une taille importante. Ruby 2.0 devrait justement régler ce problème (ou en tout cas, limiter son effet).
[^] # Re: Gitlab recommend at least 1Gb ram
Posté par GeneralZod . Évalué à 7.
Si tu cherches une alternative plus légère en terme de ressources, il y a RhodeCode.
Certes, c'est un poil moins joli, mais en plus de Git, ça gère également Mercurial.
PS: pour l'avoir testé, ça tourne sur un Raspberry PI (sans le Full Text Search pour être honnête)
PPS: si on était vendredi, j'aurais également signalé que RhodeCode est en Pylons. ;)
# Support Fusionforge Git
Posté par franck villaume (site web personnel) . Évalué à 2.
Git est aussi supporté en standard par la forge logicielle Fusionforge.
J'en profite pour signaler la sortie de la version 5.2 de fusionforge et la migration svn -> git du repository de sources de fusionforge.
# git init --bare
Posté par flagos . Évalué à 10.
Une petite astuce pour ceux qui chercheraient un moyen rapide et simple de se créer un répo en dehors de github et qui n'ont pas envie de passer 3 plombes a installer du gitlab:
git init --bare et vous avez un répo
Vous pouvez y accéder en le présentant a git comme un path unix ou un chemin ssh.
En espérant que ce sera utile a d'autres.
[^] # Re: git init --bare
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 10.
Oh my god !!! T'es en train de dire qu'avec une gestion de versions distribuée, on peut soit-même être serveur des versions ????
Perso, je trouve que c'est bien de le rappeler de temps en temps parce qu'en voyant la popularité croissante de GitHub, je me demandais si je n'avais pas rêvé quand j'avais lu décentralisé ;)
[^] # Re: git init --bare
Posté par El Titi . Évalué à 5. Dernière modification le 31 octobre 2012 à 10:16.
Plutôt que de cloner ton dépôt juste pour le partager, tu peux directement partager un dépôt non bare
avec git daemon ou avec mercurial: hg serve.
Mais je vais préparer une petite dépêche pour présenter un produit qui fait la même chose en 2 clics avec une gestion des ACL derrière http(s) et permet aussi de partager ses dépôts svn, s'administre avec un navigateur Web et permet de browser les source en ligne à distance:
SCM MANAGER
avec ses screenshots.
[^] # Re: git init --bare
Posté par feth . Évalué à 2.
Tu me mets l'eau à la bouche ! As-tu déjà utilisé gitolite (git administré… avec git) ? Ça donnerait un point de comparaison.
[^] # Re: git init --bare
Posté par El Titi . Évalué à 1.
Non, on l'avait éliminé assez tôt car il ne se déployait pas simplement sous Windows je crois.
Là il s'agit d'une simple appli Java qui se déploie en standalone avec un serveur embarqué ou distribuée comme un war à installer sur un Tomcat.
A l'époque même le git daemeon de mSysGit partait en carafe.
Il y avait un deadlock et le dev disait qu'il ne s'y connaissait pas assez en prog parallèle sous Windows pour corriger le bug.
Le dev est en plus très sympa et très réactif. Tu n'a qu'à aller voir l'activité sur ce projet.
[^] # Re: git init --bare
Posté par feth . Évalué à 2.
Uh ? Ton cas d'utilisation est de partager le dépôt directement depuis la station de travail ⁈ Parce que sinon, un serveur linux, même virtualisé, ça ne me semble pas être une dépendance difficile à satisfaire.
[^] # Re: git init --bare
Posté par El Titi . Évalué à 2.
Non on a un workflow centralisé classique. Mais on interdit pas des développeurs de collaborer directement, en attendant que le dépôt central soit créé par exemple ou parce qu'ils sont hors du réseau d'entreprise.
Ici on a besoin de pouvoir partager son dépôt rapidement et ca le fait.
Je ne dis pas que le git daemon ne fait pas l'affaire aujourd'hui mais à l'époque non.
Scm Manager couvre les 2 besoins justement.
Et en plus il est en full Java ce qui nous convient bien pour prêter main forte, s'adapte à notre archi.
D'ailleurs un de nos dev a posté le plugin d'intégration crowd.
[^] # Re: git init --bare
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Une autre astuce consiste à utiliser fossil qui est beaucoup plus simple et plus facile à decentraliser.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: git init --bare
Posté par El Titi . Évalué à 4.
Sauf que ca intègre un nouvel outil de gestion de version et qu'on ne sait pas bien s'il est à la hauteur de Git ou Hg.
[^] # Re: git init --bare
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Je l'ai testé et adopté pour remplacer git il y a bientôt 2 ans pour mes projets persos, car je perdais beaucoup de temps avec la gestion d'un ensemble git+bugtracker+site. Pour la partie gestion de version, tout ce que je peux dire, c'est que ça juste marche alors qu'avec git je me prenais régulièrement la tête avant de faire "un tant pis je commit de la merde" en écumant de rage.
Par contre, fossil ne permets pas de réécrire l'histoire, ce que les fans de git considèrent comme une friture tueuse.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: git init --bare
Posté par El Titi . Évalué à 2.
D'après ce que j'en lis ici
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
http://better-scm.shlomifish.org/comparison/comparison.html
il ne supporte pas les submodules qui est une feature capitale pour des devs un peu conséquent avec de l'édition de lien statique, ni les checkout partiels (et ls branches locales ?),ne proposa pas de stratégie de merge automatiques
et sa gestion des changesets ne semble pas supporter le groupage de commit pour faire du cherry picking.
Sinon dans la même veine des DVCS qui embarquent un bugtracker tu as aussi Veracity:
http://linuxfr.org/news/veracity-un-nouveau-gestionnaire-de-versions-d%C3%A9centralis%C3%A9
Pour coder seul, ça peut être sympa mais je me demande comment ca passe à l'échelle pour une équipe.
D'ailleurs sur le principe même du bugtracker distribué j'ai des doutes. Le fait de centraliser les demandes ca évite que 2 gugusses prennent en charge la même correction en même temps ou créent un même ticket dans leur coin le résolvent.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: git init --bare
Posté par El Titi . Évalué à 2.
Certes mais le chef de projet n'est pas derrière les devs s'ils n'utilisent pas le système comme ils le devraient.
Par exemple, en oubliant d'interroger le bugtracker de référence avant de créer un ticket et de le pusher. Et même là le schéma de concurrence optimiste ne préviendra pas des doublons.Ca me parait contre productif.
L'autre avantage que je vois à la forge centralisée comme moyen de communication et de permettre de se coordonner lorsqu'on doit modifier un fichier non mergeable du style artwork vu qu'on n'a plus de lock pessimiste avec un DVCS.
[^] # Re: git init --bare
Posté par barmic . Évalué à 3.
Et il font quoi les bug trackers actuels ? Ils évitent les doublons ? Comment ? Généralement il permettent surtout de créer des liens entre les tickets (l'un est le même que l'autre, l'un dépend de l'autre, etc).
Généralement les dev mangent un gros merge ou 2 puis apprennent à se servir de leur outils.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: git init --bare
Posté par El Titi . Évalué à 3.
Bon argument en effet.
Merger un ticket, ca revient à le lier.
Sachant que le coté distribué pourrait permettre de réorienter un ticket upstream avec un autre projet, ca pourrait avoir un intérêt.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 31 octobre 2012 à 10:16.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Que vaut GitStack ?
Posté par El Titi . Évalué à 3.
J'ai répondu plus haut scm manager convient parfaitement sous Windows pour partager son dépôt.
Il est complémentaire d'EGit qui ne permet pas de partager son dépôt et il s'intègre très bien sur un serveur de prod.
Nous l'utilisons en conjonction avec le reste de la suite Atlassian à la place de FishEye et de son futur Stash.
Il s'intègre bien a Crowd.
EGit est aujourd'hui utilisable mais il a encore quelques lacunes parmi lesquelles certaines assez gênantes, notamment:
- Il ne permet pas de suivre un merge entre 2 branches si des fichiers ont été renommés. (merge rename tracking). Assez génant quand on vend Git comme supérieur à SVN pour les branches. Pas de refactoring sans la ligne de commande
- Le stash pop t'écrase tes fichiers sans préavis y compris ceux que tu aurais modifié entre temps. A toi de faire attention a comparer ton index et le commit précédent avant le commit
- L'outil de merge n'est pas encore à la hauteur de ce qui se faisait avec Clearcase par exemple. Il te présente le fichier brut de fonderie à éditer avec les balises ou te permet juste de passer tes modifs de la source vers la cible.
Celui de clearcase te permettait de choisir le contenu que tu voulait (la cible, la source ou l'antécédant) et sa stratégie de merge 3 contributeurs te mâchait le travail lorsqu'un ligne n'était modifiée que d'un coté.
… et quelques autres irritants.
Mais globalement il est maintenant stable et fonctionnel.
MSySGit et maintenant bien stabilisé aussi et en plus ne nécessite pas de droits d'admin sur le poste pour être installé.
Bref le sempiternel "Git ne fonctionne pas sous Windows" n'est plus d'actualité.
[^] # Re: Que vaut GitStack ?
Posté par El Titi . Évalué à 2.
Pour préciser le rename tracking:
Dans la vue History en cochant "follow rename" ca marche parfaitement mais si on lance un merge entre 2 branches il ne détecte pas que le même fichier a été renommé déplacé et te crée une copie de l'ancien fichier dans ton workspace au lieu de te merger le fichier.
Ce problème n'a jamais été traité dans SVN.
http://subversion.tigris.org/issues/show_bug.cgi?id=898
Depuis la 1.1 il est remis aux calendes grecques car il nécessite une refonte de l'architecture de SVN.
Hg le gère très bien car il suit explicitement les renommages.
Git s'en sort bien avec une heuristique qui fait le diff entre 2 contenu et en reconfigurant le renamelimit au besoin.
Plus d'infos ici
http://blogs.atlassian.com/2011/10/confluence_git_rename_merge_oh_my/
Et oui après Eclipse, nos amis d'Atlassian sont maintenant passés sous Git:
http://www.drdobbs.com/architecture-and-design/migrating-from-subversion-to-git-and-the/240009175?pgno=1
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Que vaut GitStack ?
Posté par El Titi . Évalué à 2.
Quel outil utilises tu actuellement ?
Si tu es sous SVN, relis le lien que j'ai posté un peu plus haut sur la migration d'Atlassian.
Très utile.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Que vaut GitStack ?
Posté par El Titi . Évalué à 3.
Dsl, j'avais zappé dans le thread.
Alors bienvenue au 21e siècle ;)
[^] # Re: Que vaut GitStack ?
Posté par El Titi . Évalué à 2.
Sinon Scm Manager comparé à GitStack te permet de gérer des dépôts d'autres VCS (SVN, Hg), fonctionne sous Linux aussi et est surtout libre.
Il te permet aussi de démarrer en tant que service.
https://bitbucket.org/sdorra/scm-manager/wiki/daemons
[^] # Re: Que vaut GitStack ?
Posté par El Titi . Évalué à 2.
Je n'ai pas bien compris comment se positionne GitStack en terme de licence.
Il semble qu'il soit disponible sous GPLv3 mais qu'on ne puisse pas l'utiliser librement
http://gitstack.com/pricing/
Je sais bien qu'un logiciel libre n'est pas gratuit mais ça ne semble pas clair.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Que vaut GitStack ?
Posté par Anonyme . Évalué à 0.
C'est assez étonnant. Le logiciel est bien open source, et on peut voir qu'il y a bien du code pour verifier les licenses achetées et verifier que le nombre d'utilisateurs correspond au nombre de licenses :
https://github.com/smart-mobile-software/gitstack/blob/master/app/gitstack/models.py#L289
Le code de LicenceChecker par contre ne semble pas inclut.
Mais il suffirait de commenter ces quelques lignes pour ne plus etre embeté par ces histoires de licenses.
# Et la gestion de sous-modules ?
Posté par Paul Chavent (site web personnel) . Évalué à 1.
Est-ce que ça évolue de ce côté ?
J'ai toujours un moment d'hésitation quand je fait une update du supermodule. Je dois me remémorer comment vont être tirés les sous modules, comment les modifs que j'y ai apporté vont êtres gérées…
Bref, je ne me sens toujours pas à l'aise avec ce système pourtant très utile.
[^] # Re: Et la gestion de sous-modules ?
Posté par flagos . Évalué à 2.
Je ne connais pas ton cas d'utilisation mais il existe également gerrit repo qui permet de gérer ensemble plusieurs repo git.
Ca dépend du cas d'utilisation, mais autant il conviendra mieux a ton besoin.
http://source.android.com/source/version-control.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.