30

Parce que beaucoup de truc web sont en ruby...

(me demande pas pourquoi, c'est juste une daube a configurer/installer.. (toujours pas reussi a refaire marcher redmine apres une maj de ruby..)
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

31

32

Ils ont installé ce truc au boulot… Ça fait un clone de GitHub en légèrement mois joli et probablement moins bien, mais ça fonctionne. (Je n'utilise pas vraiment GitHub à part pour parcourir des sources, donc je ne saurais pas dire)
avatarLe scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

33

Il savaient que GitHub existe en version entreprise et derriere un firewall (aka la societe github n'a pas acces a ce que ca stoque)
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

34

Ah tiens, je me demandais comment ça fonctionnait justement… Je connais pas les tenants et aboutissants, mais à mon avis, la raison du choix est plutôt monétaire.

De toutes façons, j'aime pas GIT et ce truc ne va pas me réconcilier avec:
La première chose qu'il te demande en te connectant à l'interface Web, c'est de créer une clé SSH. Bien sûr, la procédure est complètement merdique sur Windows. Ensuite quand tu essayes d'ajouter la clé dans l'outil, il t'envoie complètement chier. tritop
Au final, on l'utilise avec HTTPS, et rien que ça c'est une vraie merde à configurer sur les postes (merci GIT), et je pense que personne n'a réussi ou sérieusement essayé de le configurer en SSH… :/

(Et quand tu vois le client GitHub pour Windows à côté, t'as mal au cul… C'est peut être le seul client GIT décent pour Windows en dehors de Visual Studio)
avatarLe scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

35

désolé mais vous êtes sans doute méga exigeant, tortoise git fait complètement le boulot, y compris avec ssh, via putty.

36

À ma connaissance, le seul client GIT qui fonctionne correctement sans installation de msysgit, c'est celui intégré à Visual Studio, c'est un gros point en sa faveur pour ma part: Ça marche, et c'est tout smile
avatarLe scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

37

En meme temps si tu utilise SVN, on utilise aussi généralement des clefs SSH pour éviter de taper 150000000000000000000 de fois son mot de passe pour faire un simple commit.. (et les outils fournis avec putty marchent a merveille pour ca smile)
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

38

Bah, TortoiseSVN sait retenir un mot de passe, heureusement smile
avatarLe scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

39

Et tortoisesvn est d'une lenteur...
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

40

Pourquoi crois-tu qu'il s'appelle comme ça ? grin
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

41

Oo
J'ai pas souvenir d'avoir eu de soucis à ce niveau*… Pourtant le projet que j'ai en tête est assez costaud :d

(*À part à travers une connexion internet "lente", mais alors ne parlons même pas de GIT grin)
avatarLe scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

42

./37 au taf on a pas de mot de passe. Les repos sont sur un serveur, on push via les montages réseau samba, sous le controle de nos mots de passe réseau embarrassed

43

GC: compare avec svn en ligne de command. J'ose esperer que TortoiseSVN c'est ameliore avec le temps, mais au moment ou je l'ai teste, la difference de vitesse etait superieur a *10...

squalyl: sick
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

44

GoldenCrystal (./36) :
À ma connaissance, le seul client GIT qui fonctionne correctement sans installation de msysgit, c'est celui intégré à Visual Studio, c'est un gros point en sa faveur pour ma part: Ça marche, et c'est tout smile

Le seul ? j'utilise le client GIT de Netbeans sans aucun soucis depuis un bout de temps, couplé au système d'historique et de comparaison des sources de l'IDE c'est impeccable.
avatar« Nous avons propagé sur Extranet une histoire fabriquée de toutes pièces selon laquelle une certaine disposition d'étoiles, vue depuis la planète d'origine des butariens, formaient le visage d'une déesse galarienne.
Sans chercher à vérifier ces informations, certains ont décrété que c'était la preuve de l'existence de la déesse. Ceux qui notaient le manque de preuves se faisaient attaquer. »

Legion, geth trolleur à portée galactique

45

(*À part à travers une connexion internet "lente", mais alors ne parlons même pas de GIT grin)

Pour l'expérience que j'en ai depuis 7 ans (*), il n'y a pas photo entre Git et SVN:
* un push Git d'un commit touchant des fichiers texte (au sens large) fait habituellement quelques KBs, quelques dizaines de KBs s'il y a vraiment beaucoup de changements; la même chose avec SVN nécessite plus de round trips avec le serveur, pour ce dont je me souviens et que je peux voir chez mes collègues.
* le téléchargement de toutes les révisions du repository SVN avec SVN par rapport au clonage d'un repository Git (comparons ce qui est comparable)... n'en parlons pas grin
* je n'ai pas de données sur les bandes passantes nécessaires à un checkout SVN classique et à l'obtention d'un shallow clone Git de profondeur d'historique 1;
* sur la taille disque des copies de travail / clones, en revanche, j'ai des données claires... Dans mon premier boulot, du temps de SVN 1.6, un répertoire .git contenant les plus de 10K révisions du repository SVN faisait ~400 MB, moins que les répertoires .svn contenant seulement les données pour le checkout de HEAD. SVN 1.7 a significativement optimisé les WCs SVN, mais les essais que j'avais faits sur d'autres repos montraient toujours un énorme avantage pour Git. Le futur SVN 1.9 réduira l'écart avec les DSCM.

*: au boulot, 4 repositories SVN, utilisés exclusivement à travers Git, dans mes 3 boulots successifs, et un repo Git dans ce boulot depuis plus de 2 ans pour pousser des commits de test; en temps libre, historiquement, principalement des repositories SVN, utilisés avec SVN avant l'automne 2007 et Git depuis, puis des repositories Git ces derniers temps.

Sur une machine, la mise en place d'un repo Git, avec clés SSH, avait été triviale. Sous Windows, c'est probablement moins simple, comme beaucoup d'installations - mais heureusement, je n'ai jamais eu à me soucier de cette plate-forme au boulot (et je ne compte pas avoir à m'en soucier), et en temps libre, je peux cross-compiler.


Est-ce que TortoiseSVN est aussi lent quand l'intégration shell n'est pas activée ?
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

46

nous au boulot c'est simple: svn et rien d'autres, juste parce que les révisions sont numérotées. On m'a opposé un niet concerté pour git parce qu'on n'est pas capable de dire facilement si le commit b16b00b5 est arrivé avant ou apres le commit cafefade grin

47

Après avoir utilisé git je ne repasserait pas du tout sous SVN...

Rien que le fait de pouvoir faire des branches fait que je n'ai pas du tout envie de revenir sous SVN (c'est tellement pratique). Et pour dire si les commits sont arrivés avant ou après, même sans avoir github, juste un gitweb permet d'avoir la liste des commits facilement en visuel.
(Et même si c'est trop compliqué, les gens peuvent mettre la date dans le texte du commit)

48

Tu savais pas faire des branches sous SVN ? trifus
avatarLe scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

49

Comparé à GIT, le branching sous SVN est beaucoup plus pénible.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

50

et il faut passer par le serveur pour chaque operations..

(au pire il suffit d'utiliser les TAG sous git pour numeroter les commits importants)
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

51

En effet, le branching SVN est certes meilleur que celui de CVS, mais les DSCM font beaucoup mieux.
nous au boulot c'est simple: svn et rien d'autres, juste parce que les révisions sont numérotées. On m'a opposé un niet concerté pour git parce qu'on n'est pas capable de dire facilement si le commit b16b00b5 est arrivé avant ou apres le commit cafefade grin

En effet, comme l'indique Godzil, c'est trivial d'avoir des commits numérotés avec Git, grâce aux tags Git, qui sont des étiquettes atomiques et non une lourde copie figée de tout l'arbre des sources quand on fait un checkout du repository complet comme en SVN... (*)
Tes collègues n'ont pas voulu admettre que le hash SHA1 ou son préfixe réduit ne sont pas les seules formes possibles pour référencer des commits, qu'il suffit d'utiliser un tag Git 0.1 pour pouvoir ordonner "0.1-234" et "0.1-345" (qui ne sont pas moins clairs que les révisions SVN r234 et r345) ?
Moyennant d'utiliser toujours le delta entre la révision actuelle et le dernier tag Git (comportement par défaut de `git describe`), on peut aussi réaliser un ordre total sur les commits. Avec 0.2 descendant de 0.1 et 0.1-345 antérieur à 0.2, 0.2-234 est ultérieur à 0.1-345.

*: dans mon miroir du repository de mon premier boulot, que j'ai conservé puisqu'il s'agit d'un projet open source, les tags SVN, branches SVN, et autres sandbox et répertoires spéciaux (je ne pouvais pas utiliser le layout standard de SVN puisqu'on utilisait plusieurs répertoires agissant comme branches, et je crois qu'à l'époque, mes essais de spécifier plusieurs arguments branches n'avaient pas donné les résultats espérés), sont responsables de l'immense majorité des plus de 140000 fichiers dans plus 60000 de répertoires de mon checkout, représentant 5 ans après toujours presque 10% des entrées dans les tables de cette partition.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

52

non, une numerotation humaine est faillible, et en pratique, ca ne marche pas. il y aura au moins un oubli qui va tout peter. et on ne veut pas numeroter juste quelques commits, parce que quand on teste des release candidates, on a pas envie de les tagger definitivememt.

au moins les numeros de rev svn sont incontournables, infaillibles, strictement croissants, et automatiques.

de plus l'absence de $subst$ built-in imposee theologiquement par torvalds est derangeante, chez nous c'est indispensable, ne serait ce que pour afficher le dernier auteur.

pour les revision de fichiers multiples on utilise svnrev en prebuild step et ca finit directement dans le binaire final, git ne peut pas faire ca aussi facilement.

ceci dit pour une utilisation perso il y a longtemps que je n'utilise plus svn smile

53

et on ne veut pas numeroter juste quelques commits, parce que quand on teste des release candidates, on a pas envie de les tagger definitivememt.

Justement, le fait de les tagger définitivement permet de retrouver directement la révision exacte d'une release candidate, et ça ne coûte que quelques octets.
Linux, et d'autres, utilisent plusieurs tags Git par release, et ils en ont l'air contents.
au moins les numeros de rev svn sont incontournables, infaillibles, strictement croissants, et automatiques.

D'accord avec toi. Infaillibles, strictement croissants, et automatiques, oui. Incontournables, forcément, il n'y a pas grand chose d'autre ^^
Après, si on fait un tant soit peu attention à ce qu'on fait, la sortie de `git describe` est, entre autres, strictement croissante.
de plus l'absence de $subst$ built-in imposee theologiquement par torvalds est derangeante, chez nous c'est indispensable, ne serait ce que pour afficher le dernier auteur.

Hmm... ça vous arrive souvent, d'avoir besoin de déterminer l'auteur du dernier commit sur un fichier ?
Surtout que ça ne fournit qu'une information très partielle. Si on veut vraiment retrouver qui a introduit un problème dans la base de code (en général, il porte sur un petit sous-ensemble du fichier), c'est `blame` qu'il faut utiliser, et à ce moment-là, pas de différence fonctionnelle entre SVN et Git. Bien sûr, l'un a besoin d'un accès au serveur central, et pas l'autre.
ceci dit pour une utilisation perso il y a longtemps que je n'utilise plus svn smile

Voilà, je pense qu'on en est pour la plupart là, nous avons laissé derrière nous les outils du passé.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

54

Oué. M'enfin :
* SVN ne permet pas de réécrire l'histoire.
* Je me suis déjà fait des putains de frayeurs avec GIT avec un rebase qui s'est mal passé, et une perte de plus de 100 commits dans une branche ! (J'ai finalement réussi à réparer la branche, mais avec SVN j'aurai pas eu à le faire).
* SVN supporte les répertoires vides.
* SVN support la gestion de conf de fichiers binaires.

55

SVN ne permet pas de réécrire l'histoire.

Ca, c'est un vilain défaut. Très vite, je n'ai plus pu me passer de la réécriture d'historique intégrée de Git, pour un historique des commits plus linéaire et plus facile à bisecter. On s'en fout de tous les commits incomplets et buggés qu'on a fait lors du développement (des conneries, on en fait toujours). Si on peut réécrire pour faire un truc propre avant de diffuser, c'est une feature importante smile
Réécrire les branches remote sur un repository public, c'est largement considéré comme très vilain, pour des raisons en général bonnes.
Quand on n'a pas la réécriture d'historique, il faut avoir recours à plusieurs outils (quilt + SVN, par exemple) plutôt qu'un seul (Git).
Je me suis déjà fait des putains de frayeurs avec GIT avec un rebase qui s'est mal passé, et une perte de plus de 100 commits dans une branche ! (J'ai finalement réussi à réparer la branche, mais avec SVN j'aurai pas eu à le faire).

Forcément, traditionnellement, SVN ne sait pas rebaser, et de plus, son merge est moins malin que celui de Git, même s'il est amélioré au fil du temps ^^
Mais sinon, je compatis, bien que je ne me sois pas trouvé dans la situation d'avoir à faire ce genre de réparations. Je n'ai pas non plus eu des branches aussi longues par rapport à une branche principale qui évolue en parallèle, seulement jusqu'à ~25 commits.
SVN supporte les répertoires vides.

C'est un fait, mais le contournement de cette absence de support par Git (qui s'explique par des raisons semi-techniques) n'est quand même pas difficile wink
Le fichier placeholder peut d'ailleurs très bien être un .gitignore, comme dit plus haut.
SVN support la gestion de conf de fichiers binaires.

On peut bien entendu mettre des fichiers binaires dans Git, mais c'est connu que Git (seul) n'est pas le plus doué pour leur gestion, en effet.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

56

Lionel Debroux (./55) :
Ca, c'est un vilain défaut. Très vite, je n'ai plus pu me passer de la réécriture d'historique intégrée de Git, pour un historique des commits plus linéaire et plus facile à bisecter. On s'en fout de tous les commits incomplets et buggés qu'on a fait lors du développement (des conneries, on en fait toujours). Si on peut réécrire pour faire un truc propre avant de diffuser, c'est une feature importante smile.gif?9
Réécrire les branches remote sur un repository public, c'est largement considéré comme très vilain, pour des raisons en général bonnes.Quand on n'a pas la réécriture d'historique, il faut avoir recours à plusieurs outils (quilt + SVN, par exemple) plutôt qu'un seul (Git).


Pour moi, réécrire l'histoire reste la pire cochonnerie qu'un gestionnaire de version peut faire (en fait, GIT ne réécrit pas l'historique des commits mais écrit un nouvel historique des modifications à partir de la racine, puis oublie où se trouve l'ancienne histoire - je pense qu'on doit pouvoir retrouver l'histoire avant rebase en cherchant bien).
Lionel Debroux (./55) :
On peut bien entendu mettre des fichiers binaires dans Git, mais c'est connu que Git (seul) n'est pas le plus doué pour leur gestion, en effet.

On peut les mettre, mais on peut pas faire leur gestion de conf avec.

57

Tant qu'on n'a pas fait de gc, en effet, on peut retrouver les vieux commits. Mais ça a rarement de l'intérêt pour moi. En général, on se fout des commits incomplets / buggés / de test qu'on a faits au cours du temps.
J'utilise la fonctionnalité connue comme réécriture d'historique (même si techniquement elle n'en est pas, nous sommes d'accord) locale quotidiennement, et la réécriture d'historique distante forcée (sur un repo que je suis le seul à utiliser, je vous rassure grin) quasi-quotidiennement.

Dans l'historique publié, la bisectabilité est utile, même dans les petits projets (`git bisect` m'a déjà aidé plusieurs fois au boulot), ne parlons pas du kernel Linux où elle est absolument indispensable. Or, le commit-and-fix nuit gravement à cette bisectabilité, alors que la réécriture d'historique est un des principaux outils de cette bisectabilité.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.