Et tu peux nous expliquer pourquoi ? Qu'est ce qui a justifié ton choix de Perforce ? Quels sont les avantages ? Les Pour et Contres par rapport à SVN ou GIT ?
Disons en fait que je suis forcé d'utiliser ça au bureau Autrement, j'utilisais plutôt SVN auparavant. Je n'ai pas vraiment de pour et de contre. Je n'avais jamais configuré un serveur SVN. Mon premier aura été avec P4D (Perforce Server), et la simplicité de mise en place est assez agréable.
Concernant mes projets partagé avec tous ceux que je ne connais pas c'est github, sinon si c'est un projet partagé dans un cadre restreint c'est mon serveur svn.
J'ai tendance à dire que GIT est merdique non pas sur le papier mais à cause de la ligne de commande qui va avec ! Certe c'est cool de plus avoir les .svn de partout, le système décentralisé peut avoir du bon, par contre la ligne de commande ils se sont raté en plein...
Il y a trop d'action pour faire un simple commit, d'ailleurs on est obligé d'écrire commit en toute lettre, il n'y a pas de raccourcit type ci... Et lorsqu'on le fait, on est obligé de mettre un message de commit, un -m "" ne marche même pas ! Alors OK c'est pas bien de pas mettre de message de commit, mais ça reste à moi humain d'en décider, pas à la machine !
C'est pour ces détails que je n'aime pas GIT pour la ligne de commande qui va avec ! Sérieusement on dirait qu'elle a été faite par Microsoft ! Plein d'action de confirmation et des commutateurs à rallonge...
Pour les commandes a ralonge, je n'utilise pas le quart des commandes qui existent. Et celle que j'utilise le plus souvent restent simple, mais je n'ai pas eut à gérer de gros merge.
dans 1274787993:
dans 1274783363:
Les rares exemple que j'ai pu rencontrer c'était un gros repo avec pour chaque projet un dossier. Et faire mumuse avec l'URL pour taper le projet concernait. Rien de mieux a proposer
Bah c'est ce que j'ai fait justement, mais ça ne semble pas être compatible avec GIT qui ne permet d'accéder qu'à la racine. Je peux bien mettre des URLs vers un dossier particulier de mon repo sur github pour que les utilisateurs aillent directement browser dans ce sous-dossier, mais après ils peuvent rien en fait de plus : s'ils veulent faire un checkout (enfin cloner le repo GIT) ils ne peuvent que cloner la totalité, pas qu'une sous-partie. Pareil s'ils veulent télécharger un snapshot ZIP (par exemple parce qu'ils n'ont pas de client ZIP et veulent juste récupérer mon code), ils ne peuvent que récupérer un snapshot de l'intégralité du repo.
Et c'est tout mon problème.
Alors qu'avec SVN je crois que y'a pas ce souci, puisque chaque dossier a son propre ".svn" et peut être checkouté indépendamment de la hiérarchie parente.
C'est vrai que c'est "une régression" l'impossibilité de faire un checkout partiel d'un dépôt git.
Du coté de git, il me semble qu'il est possible de ne récupérer que les derniers commit d'un dépot git avec l'option --depth. attention un tel clone à des limites :
--depth <depth> Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.
Pour les commandes a ralonge, je n'utilise pas le quart des commandes qui existent. Et celle que j'utilise le plus souvent restent simple, mais je n'ai pas eut à gérer de gros merge.
C'est bien la tout le problème de GIT et de pas mal de bon logiciel issue du monde libre, ils sont TROP libre... J'ai déjà "perdu" une journée à me lire la doc de comment GIT est pensé avec leurs dépôt décentralisé, j'ai pas une autre journée à perdre à me faire une config qui faut ensuite répliquer sur chaque machine et replacer à chaque install... Ce sont des outils fait pour des développeurs, pas pour des gamins ! Il devrait y avoir des versions courtes des commutateurs d'entrée de jeu, comme c'est le cas avec svn...
Sur git le principe de dépot dans tous les sens peut être intéressant, l'absence de .svn encore plus, mais je trouve sérieusement qu'ils ont raté tout le reste... Ils ont oublié qu'on utilise GIT non pas par plaisir mais par besoin, il faut donc que GIT se fasse oublier le plus possible à mon sens...
Dans mes souvenirs, il me semble que linus ne considérait pas git comme un outil de gestion de source, mais qu'il était plus proche d'un système fichier.
Je ne sais si possible dans ton cas, mais peut être qu'une migration vers mercurial serait à envisager. Il sait se faire oublier et plus proche de svn dans ses commandes que git. Sans compter que sur notre plateforme, il y a des outils graphiques qui semblent pas mal du tout (je pense à Murky et à MacHG).
C'est vrai que créer un serveur SVN est super compliqué, il faut taper
svnadmin create nomdemonnouveaurepository
dans le terminal et valider... dur Quand à GIT, un
git init
dans le terminal également, encore plus simple... Alors j'ose pas imaginer la simplicité de P4D vu ce que tu décris
Je suis pas venu démonter SVN ou GIT, ni défendre P4V. Le versioning je m'en passerai sans problème chez moi. Je voulais juste faire remarquer que je devais utiliser P4V au boulot... parce que la dite boà®te a des méthodes disons, archaà¯que, mais chut :P
Réponses
Qu'est ce qui a justifié ton choix de Perforce ? Quels sont les avantages ? Les Pour et Contres par rapport à SVN ou GIT ?
Autrement, j'utilisais plutôt SVN auparavant.
Je n'ai pas vraiment de pour et de contre. Je n'avais jamais configuré un serveur SVN. Mon premier aura été avec P4D (Perforce Server), et la simplicité de mise en place est assez agréable.
Restera un gros contre: la license. On est limité, il me semble, à 2 ou 3 utilisateurs. Après, je vous laisse voir les prix : http://www.perforce.com/perforce/price.html
Quand à GIT, un dans le terminal également, encore plus simple...
Alors j'ose pas imaginer la simplicité de P4D vu ce que tu décris
Pour le problème du git ci, il existe les alias dans git qui permet d'en définir. https://git.wiki.kernel.org/index.php/Aliases
Pour les commandes a ralonge, je n'utilise pas le quart des commandes qui existent. Et celle que j'utilise le plus souvent restent simple, mais je n'ai pas eut à gérer de gros merge.
C'est vrai que c'est "une régression" l'impossibilité de faire un checkout partiel d'un dépôt git.
Du coté de git, il me semble qu'il est possible de ne récupérer que les derniers commit d'un dépot git avec l'option --depth. attention un tel clone à des limites :
Du coté de mercurial, ça réfléchit aussi à ce problème : http://mercurial.selenic.com/wiki/PartialClone
C'est bien la tout le problème de GIT et de pas mal de bon logiciel issue du monde libre, ils sont TROP libre... J'ai déjà "perdu" une journée à me lire la doc de comment GIT est pensé avec leurs dépôt décentralisé, j'ai pas une autre journée à perdre à me faire une config qui faut ensuite répliquer sur chaque machine et replacer à chaque install... Ce sont des outils fait pour des développeurs, pas pour des gamins ! Il devrait y avoir des versions courtes des commutateurs d'entrée de jeu, comme c'est le cas avec svn...
Sur git le principe de dépot dans tous les sens peut être intéressant, l'absence de .svn encore plus, mais je trouve sérieusement qu'ils ont raté tout le reste... Ils ont oublié qu'on utilise GIT non pas par plaisir mais par besoin, il faut donc que GIT se fasse oublier le plus possible à mon sens...
il me semble que linus ne considérait pas git comme un outil de gestion de source, mais qu'il était plus proche d'un système fichier.
Je ne sais si possible dans ton cas, mais peut être qu'une migration vers mercurial serait à envisager. Il sait se faire oublier et plus proche de svn dans ses commandes que git. Sans compter que sur notre plateforme, il y a des outils graphiques qui semblent pas mal du tout (je pense à Murky et à MacHG).
J'utilises
http://bitbucket.org/
Et j'en suis plutôt content même si je m'en sers plus comme sauvegarde que comme outils de partage
Il y aussi le coup du wiki qui n'est qu'un dépôt mercurial (différent de celui utilisé par les sources).
Les deux outils que j'ai cité précédemment sont hébergés sur ce service.
Je suis pas venu démonter SVN ou GIT, ni défendre P4V. Le versioning je m'en passerai sans problème chez moi.
Je voulais juste faire remarquer que je devais utiliser P4V au boulot... parce que la dite boà®te a des méthodes disons, archaà¯que, mais chut :P