Reprise du message précédent :

on commence a le savoir que t'as un truc contre les gays...
 
Comme Hitler.

Hitler adorait les gays, il les nommait généraux, c'est scandaleux de ne pas connaître un partie aussi important de notre histoire  

Et il était végétarien aussi

Mais c'est qui qui a pris le ban ?

Le plus sain, c'est quand même de fermer tout le topic pour pas avoir dénoncé le fauteur de trouble, comme pour le topic gif, franchement t'avais trop bien géré

EDIT : A+,

dernz

I'm the last man standing

lolz  

J'ai un nouveau tel

On veut un test complet

la j'ai fait attention, j'(ai alerté le plus vite possible

blabla

Hoï  

J'adhère, le delete du topic est aussi une solution satisfaisante

En plus ça fait longtemps qu'on a pas eu de splits

Je suis en train de regarder les DVCS (Git principalement et un petit peu mercurial, mais le choix résulte plus du hasard que d'autres choses, si d'expérience vous savez qu'un autre est mieux) pour un petit projet perso. Et j'ai la forte impression que je manque quelque chose.  Ces systèmes m'ont l'air d'avoir fusionné les concepts de repository et de workspace.  Et j'ai deux problèmes:
- ça ne me semble pas passer à l'échelle.  C'est pas un problème dans mon contexte immédiat, mais au boulot j'ai six workspaces.  Si chacun a 6 copies complètes du dépôt, ce sont les fabricants de disques qui vont être contents mais personne d'autre.  En fait, je ne suis pas sûr de tout de vouloir une copie complète du dépôt principal même quand je veux un dépot plus local (comme sur un portable, l'historique des branches sur lesquelles je ne travaille pas, je m'en fous).
- si au départ on peut découper en sous-projets pour avoir des dépôts organisé d'une telle façon qu'on ne désire pas des parties d'un d'entre eux, je ne compterais pas que ça reste comme ça.  Et je n'ai pas vu comment prendre qu'une partie de la hiérarchie servie par un dépôt.

- les dépots de DCVS ne prennent pas tant de place que ça
- tu pull juste un sous chemin de ton depot non ?

Je préfère mercurial personnellement, pour des raisons de clarté et simplicité de la CLI.

Oui et non, il est plus correct de dire que chaque working copy a son repository. C'est le repo qui est distribué, sinon c'est pas un repo. Mais il y a toujours une distinction entre le repository et la working copy (et, dans git, l'index)

1. Le disque, ça coûte rien, surtout quand tu fais de la prog. Sauf à être sur des projets gigantissimes c'est franchement mineur. Surtout que git et mercurial ont des branches "en place", donc pas besoin d'avoir 2 WC différentes pour bosser sur 2 branches différentes (sauf s'il faut bosser vraiment complètement simultanément dessus à la limite)
2. Un CVCS va généralement garder une version pristine des fichiers de la WC histoire de pas avoir à taper dans le serveur pour un status, un diff ou un revert (svn le fait en tout cas). Sur la majorité des projets, ces duplicatas engendrent plus de données que le stockage local du repo

Ma question serait plutôt pourquoi tu ne la voudrais pas.

Sauf que si dans 2j tu décides de bosser dessus tu l'as dans l'os.

Pas. Pas pour bosser en tout cas. Dans la majorité des DVCS, un repo est un objet "atomique" (raison pour laquelle il n'y a généralement pas de repos par organisation ou service, mais des repos par project). Par contre il y a des concepts de "subrepos" dans lequel un dépôt "maître" va dépendre d'un repo "enfant". Le repo enfant n'est pas au courant qu'il est intégré où que ce soit et peut être cloné et manipulé indépendament de son parent (c'est similaire aux externals d'svn en comportement)

Globalement, j'ai quand même l'impression que tu décides que quelque-chose qui est généralement sans importance aucune est soudainement un problème pour toi, sans même d'observations/expériences allant dans ce sens.

Non, sauf si tu as un historique vraiment gigantesque ou bien des fichiers binaires régulièrement modifiés.

@masklinn; ok pour l'historique

Bon anniv' Harko!

blabla

 
T'as attrapé la blablate ?  
 
 
Bon anniv' Harko!

je préfère la solution du bouc émissaire , au hasard Harko

 
Il y a un effet quadratique: plus un projet est gros, plus il y a de personnes qui travaillent dessus.  Du point de vue de l'organisation, dupliquer est de moins en moins pertinent.
 

 
Si c'est possible, j'ai pas encore vu une mention du fait.
 

 
Je regarderais donc mercurial plus en profondeur.
 

 
D'accord.
 

 
Je ne sais pas si c'est dans le gigantissime: projet commencé dans les années 80 avec depuis que j'y suis deux ou trois cents programmeurs.  Et les tests qui sont naturellement versionnés utilisent des données binaires de taille respectable -- qui bougent relativement peu, mais qui bougent quand même.
 
Il faudrait que j'aille voir la taille du cache Perforce qu'on est une vingtaine à l'utiliser.  S'il faut la multiplier par 100 (20 personnes à 5 workspaces), c'est pas rien.  Et de mémoire, ce cache ne contient pas les branches sur lesquelles personne chez nous travaille.
 

 
Même en supposant que j'introduirais des branches quand pour le moment je n'en introduit pas, passer à moins de 4 workspaces demanderait de réorganiser fortement ma méthode de travail.
 

 
Il garde une copie des fichiers qu'on n'a pas modifiés?  Je ne vois pas l'intérêt.
 

 
Je ne vois pas pourquoi j'irais bosser sur la branche destinée à un sous-projet différent.
 

 
Je vais voir ça. (J'ai pas vu mention de ça dans ce que j'ai lu sur git jusqu'à présent).
 

 
Pour le moment, je ne décide rien.  Je n'investigue que depuis hier, je n'ai fait que lire et jouer un peu avec deux ou trois commandes, suffisamment pour avoir l'impression que j'ai bien compris l'usage suggéré mais pas assez pour que les problèmes de changement d'échelle apparaissent.  Comme c'est pour un petit projet perso, ces problèmes apparaîtrons pas mais tant que je n'ai pas connaissance d'une solution ou l'assurance que ce sont des limitations connues, j'aurais l'impression de ne pas avoir réellement compris le modèle d'utilisation prévue.  Et vu que ce qui me tracasse est tellement des non-problèmes pour les auteurs qu'ils n'en font pas mention, chercher plus de renseignements est difficile. Il est vraisemblable qu'une partie des problèmes sur lesquels je m'interroge sont juste des questions d'organisation.  Il y a une complexité que nous gérons pour le moment d'une certaine façon.  J'ai l'impression que passer à un DVCS forcerait à gérer cette complexité d'une autre façon (chose qui n'a pas été nécessaire lors du passage d'un système propriétaire à CVS ni de CVS à P4). Découper notre dépôt unique en sous-dépôts semble la voie pour si j'ai bien compris le modèle d'utilisation sous-jacent dans tes commentaires. Le résultat final ne serait probablement ni plus simple ni plus compliqué que l'état actuel si c'est bien fait.  Reste à être sûr de bien le faire (c'est quoi la granularité à utiliser dans la découpe) car il y a un risque certain.

juste pour etre sur, tu parles de quelle ordre de grandeur de taille ? Mo ? dizaine de Mo ? centaine ? Go ?

aujourd'hui, meme sur un portable  d'entree  de gamme tu as 450/500 Go dispo une fois l'installation de l'os et de outils faite ( hors ssd)

Gilou C'est quand même le mec énorme, il demande à être modo, dans un forum où leur seul pouvoir est de faire chier les posteurs (et déplacer les topics), il n'apparaît ici uniquement pour en faire chier un où après en voir fait chier un, mais il considère qu'il existe des catégories de gens qui sont moins indispensables que lui.

C'est parce que les autres modos ne sont jamais là, on a les modos qu'on mérite

http://www.rue89.com/making-of/201 [...] les-176930
 

 

 

Avec des contraintes comme ça, c'est pas nécessairement un worst-case pour un DVCS (un worst-case c'est du jeu vidéo, ou encore pire des projets uniquement média genre albums ou montage vidéo), mais si un DVCS est potentiellement une piste à explorer c'est pas nécessairement un truc auquel switcher, même en ignorant la contrainte sociale/apprentissage.

Avec un DVCS les branches ne sont pas nécessairement introduites au sens de publiées, ce sont aussi des espaces de travail privés à court (jours) terme, j'utilise de courtes branches pour expérimenter, pour pouvoir faire plusieurs trucs en parallèle sans qu'ils se polluent l'un l'autre, pour isoler la création de nouvelles fonctionalités du fixage de bugs, ... quand ça coûte rien à créer ou à merger et que ça reste invisible pour les autre, c'est bien pratique.

T'as pas le choix à ce que je sache, si t'as un VCS lockless ou à locks optionnels. C'est soit ça soit devoir aller taper dans le repo central à chaque invocation.

Ce qui semble logique, dans la mesure où par exemple CVS et P4 implémentent fondamentalement le même modèle

Oui, si votre modèle actuel c'est un repo unique avec tous les projets de la boite ou du groupe dedans, c'est pas viable avec un DVCS. C'est peut-être faisable mais ça va être plus chiant qu'autre chose. D'un autre côté, créer et partager de nouveaux repos est généralement rapide et pas très difficile avec un DVCS, donc il n'est pas très gênant d'avoir des "nuages" de repos.

En termes structurel, c'est certain.

Yo, petit coucou depuis le cafe ou J.K. Rowling ecrivait ses premiers Harry Potter.
Vu le temps pourri dehors, j'ai une heure a tuer avant de partir pour l'aeroport.

Qh et bonannif Harko !

http://forum.hardware.fr/hfr/Progr [...] 1498_1.htm
 

c'est un programme avec un cul, pour faire de la merde

http://www.facebook.com/group.php? [...] 884&v=wall
La vie en Banlieue ...

Bof, pas pense, d'toute facon, les bons single malts, on les trouve dans tous les Nicolas de France a pas trop cher
Apres ici, on en trouve qui ne sont pas exportes, mais avant de gouter a ceux-la, il y a deja les autres

la chance de vivre dans  proche d'une grande ville

Haskell ( et le déclic «je commence à comprendre ce language de fou»), un Cappucino, une couette, une pipe. What else?

 
nos locaux sont au même étage (2 entreprises) on a eu de la chance  

c'est pas de la chance, vous ne faites pas chier le gouvernement vous  

benou au moins il est pas chiant ²

Il est encore moins présent que gilou...