Je cherche des alternatives gratuites TFS pour gérer le code source. J'ai travaillé avec CV et SVN. Je sais git et mercurial, mais je n'ai toujours pas travaillé avec eux.
Je voudrais utiliser quiconque d'entre eux intégré à Visual Studio, avec la même facilité qui utilise TFS (Menu contextuel de la solution Explorateur, un explorateur de source loquable, etc.).
Savez-vous des plugins gratuits pour faire cela?
6 Réponses :
J'ai utilisé "ankhsvn" ( http://ankhsvn.open.collab.net/ ) Plugin pour accéder à SVN. Travaillé comme un charme :)
J'utilise mercurial avec TORTOISHG qui fournit des menus contextuels et des icônes de statut d'Explorer et le Le niveau d'intégration avec Visual Studio n'est pas aussi léger que le niveau d'intégration que vous obtenez avec TFS, combiné néfaste, ils font un environnement de travail très productif. En fait, dans certaines zones, je préfère l'intégration sur l'intégration TFS - en particulier, je trouve l'explorateur TFS un peu encombrant, car il exige qu'une instance de VS soit en cours d'exécution. En revanche, l'explorateur de référentiel de tortuehg est très léger et rapide à démarrer.
Je suggérerais fortement d'utiliser mercurial.
avec Visual Studio, il y a un plugin gratuit http://visualhg.codeplex.com/ .
En outre, vous pouvez installer un paquet Windows Shell que vous pouvez installer appelé Tortisehg, ce qui le rend super facile à gérer avec Mercurial sous Windows. http://tortoisehg.bitbucket.io/
Il existe d'autres plugins que vous pouvez utiliser pour SVN et GIT.
Pour GIT, vous pouvez utiliser MSYSGIT, qui a de nouveau avec de bonnes caractéristiques d'intégration de shell: http://code.google.com/p/msysgit/
ainsi que des extensions de studio visuelles http://code.google.com/p/gitextensions/
Pour SVN, il existe Ankhsvn http://ankhsvn.open.collab.net/
Si vous n'avez pas utilisé beaucoup de SCM, je recommande vivement d'essayer de sortir mercuriaire. Les SCM distribués deviennent rapidement le moyen optimal de traiter le contrôle de la source. C'est juste la bonne façon de faire des choses.
Voici quelques ressources pour vous aider à démarrer si vous êtes intéressé par Mercurial:
Excellent tutoriel de Joel Spolsky: http://hginit.com/
Couverture approfondie des caractéristiques mercuriales: http://hgbook.red-bean.com/
meilleure des chances.
Si vous utilisez Tortoise SVN et Visual Studio, je recommande vivement visualsvn plugin Visual Studio. Ce n'est pas gratuit, mais ça vaut bien l'argent.
Le plugin est vraiment sympa, mais SVN ne peut pas rivaliser avec Mercurial et Git.
J'utilise Extensions GIT . Il a de bonnes vitrines Windows Gui et Visual Studio Plugin. Cela fonctionne avec Cygwin et Msyssgit.
Appuyé. Les extensions GIT intensivent très bien avec VS, et comprennent également des outils d'interface graphique autonome et une coquille de ligne de commande (par le regroupement de Cygwin et MSYSGIT).
Je n'ai pas fait beaucoup de choses avec GIT pour le moment, mais si vous connaissez SVN et que vous travaillez sous Windows, vous avez peut-être trouvé des tortoisisvn. Je recommande de donner Tortoisegit A TRY.
En fait, je ne vois pas de besoin d'une intégration étroite dans Mme Visual Studio. Je travaille actuellement avec accès et (honte sur moi) Visual Basic 6, et il n'y a aucune intégration de subversion. CheckIn / Out, affichage des journaux, de la ramification et de nombreuses autres choses fonctionnent assez bien sous TortoiseVN.
La dernière fois que j'ai utilisé cette intégration était visual Sourceforge, qui par défaut fournit des serrures de fichier. Cela a rendu nécessaire d'avoir une bonne intégration. Comme SVN et Git ne fournissent pas de serrures en premier lieu, je préfère utiliser un client autonome.
Une fois que vous avez utilisé l'utilisation de GIT à partir de la ligne de commande, vous n'essayez pas de trouver un plugin / add-in pour VS plus
De même à @Ocar, je suggérerais que l'intégration avec VS peut-être pas aussi grosse affaire que vous pourriez penser. Je ne suis pas un gourou de ligne de commande, mais je me suis habitué à utiliser un Outil externe , et je le préfère en fait. Il conserve le codage et le «bookwork» séparé.