Est la Version de Contrôle nécessaire pour un petit groupe de développement (1-2 programmeurs)?
Je suis en train de débat, au point que le contrôle de version est important pour un ou deux développeurs.
Plus précisément, je travaille dans un département dans lequel il y a généralement deux développeurs PHP, à l'aide d'un cadre commun. Il soutient qu'il n'existe pas de valeur ajoutée à nous avoir Subversion installé sur notre système de développement, alors que je suis persuadé qu'il est agréable de temps en temps de pouvoir rouler en arrière pour voir le code précédent, surtout quand il ya inexplicable erreurs qui sont difficiles à cerner dans certaines classes.
Je pense que la Subversion offre le moyen le plus facile de créer et de suivre les changements, pour diverses raisons, y compris le débogage. Serait Subversion enregistrer n'importe quel moment?
- Je travaille moi-même, mais j'ai aussi utiliser le contrôle de version. C'est la valeur même dans une équipe de 2.
Vous devez vous connecter pour publier un commentaire.
Je vais juste pile sur ici et de dire OUI. Comme @17 de 26 dit
C'est la vérité. J'ai fait de petits projets à la fois avec et sans contrôle de code source (pas mon choix). Sans, il aspire tout simplement. Il n'existe pas de version canonique du projet, vous ne savez jamais qui est ce et modifications de la fusion est un exercice de douleur.
Vraiment bien, rien de plus environ 5 lignes de code doit être sous contrôle de version d'une certaine sorte.
Vous toujours, toujours voulez avoir une sorte de Contrôle de code Source, même si vous travaillez sur un projet par vous-même.
Avoir un historique des modifications est essentiel pour être en mesure de voir l'état d'une base de code à un moment donné. Il existe une variété de raisons, en regardant en arrière dans l'historique des projets qui vont du simple fait d'être en mesure de restaurer un mauvais changement de fournir un soutien pour un vieux relâchez-le lorsque le client veut juste un patch pour corriger un bug plutôt que la mise à niveau vers une version plus récente du logiciel.
De ne pas avoir une sorte de contrôle à la source est de la pure folie.
Oui catégorique.
Même si vous êtes un seul programmeur, vous avez besoin de contrôle de version. La simplicité avec laquelle vous pouvez comparer le code instantané dans le temps est inestimable.
Mon avis - allez-y!
[Une fois, je vivais sans contrôle de version. Maintenant je ne peux plus.]
Je suis UN programmeur et je trouve essentiel, comme je l'ai parfois envie de rouler des choses en arrière, ou de comparer une chose à une version antérieure.
Aussi, j'ai la version des documents auprès des utilisateurs et des choses comme ça.
C'est un excellent moyen pour suivre votre développement.
De contrôle de Version sera sauver ton cul. Un développeur professionnel de ne pas utiliser le contrôle de version est l'une des rares choses qui sans contredit la relève de la catégorie des logiciels de faute professionnelle.
Même si vous êtes un développeur solitaire il
Si vous êtes plus d'un développeur, il gardera un programmeur d'écraser les modifications apportées à un autre programmeur qui sera arriver, peu importe comment vous êtes attentif.
Ce sont juste les bases qui devraient vous aider à gagner un argument quant à savoir si ou de ne pas utiliser le contrôle de version.
Subversion -- absolument pas. Il est centralisée et la fusion de soutien n'est pas si bon.
De contrôle de Version -- OUI, absolument! Même en solo développeur a besoin!
Et des petites et rapide de se déplacer, des équipes mobiles, des besoins de contrôle de version distribué, afin de choisir l'une des opérations suivantes:
Oui, il y a une courbe d'apprentissage. Aller distribuées, vous pouvez l'apprendre. Et oui, vous pouvez me remercier plus tard.
Et où ces référentiels distribués vivre? Voici quelques idées:
Je suis un "one man band" programmeur et j'ai enfin commencé à utiliser le contrôle de version quand j'ai trouvé moi-même la copie de l'ensemble des applications et de les mettre dans un dossier nommé "backup", puis plus tard, de les nommer quelque chose comme "20080122 de sauvegarde". J'imagine que beaucoup de personnes commencent de cette façon. Donc, la question n'est pas de savoir si ou non vous devez utiliser le contrôle de version, mais plutôt si vous le faites de la bonne façon, ou si vous hack ensemble, certains à moitié maison de télécopieur?
De contrôle de Version n'est nécessaire que lorsque le nombre de programmeurs est > 0.
Utiliser quel que soit le système fonctionne et que vous êtes à l'aise avec, mais si vous n'développement alors vous avez besoin de contrôle de version (idéalement mis en place de telle manière que la source est sur au moins deux machines avant même que vous vous inquiétez au sujet des sauvegardes).
Au - delà, chercher un système qui vous permet de valider tôt et commettent souvent.
Je suis presque bizarre bien que cela puisse paraître - en route vers le point de vue que chaque projet, même un de 1 dev - doit être à la recherche à l'intégration continue, c'est à dire d'avoir ce système construit et testé, à partir de zéro, chaque fois que des modifications sont validées ou au moins sur une base régulière. Pourquoi? Cette une) vous donne la confiance que vous avez une constructible système VCS et b) permet de s'assurer que vous avez réellement besoin d'un nettoyage construit pour tester et déployer.
Je ne sais pas à propos de la Subversion en particulier, mais je crois que chaque projet, même avec un seul développeur, doivent utiliser le contrôle de version. Je regarde quelques options (CVS, SubVersion, git, Bazaar, Visual SourceSafe) et de voir lequel(s) de rencontrer des membres de votre équipe désire le meilleur.
De Contrôle de Version est l'outil le plus important qu'un programmeur a, même plus importants que les langages de programmation. Peu importe combien d'utilisateurs que vous avez, contrôle de la source doit toujours être exigée. Je ne sais pas combien de fois j'ai fait une modification de rupture et puis le besoin de revenir et de travailler sur de l'ancien code ou, au moins, il suffit de voir comment le code original a fonctionné. Je travail en petites équipes et nous l'utilisation de SVN Notifiant, laissez-nous savoir quand les choses sont engagés. Cela nous permet de revoir le travail de chacun et vous n'obtenez pas le redoutable "Avez-vous vérifié votre code dans encore?" des questions tout le temps. À l'aide de la source de contrôle à partir du début permettra d'éliminer beaucoup de maux de tête (remplace, code perdu, les combats pour qui a changé quoi) que vous pouvez rencontrer.
Absolument. Il n'y a vraiment pas d'autre façon de traiter avec des restaurations à un bon état lorsque le codage chemin vous aventuré s'avère être dense avec les loups.
Et vous pouvez le sauvegarder.
Quelqu'un qui ne fait pas de contrôle de version est tout simplement de faire le mal.
J'ai un projet que je suis seule à travailler sur et de Contrôle de Version me rend la vie tellement plus facile. Par exemple, supposons que je décide de mettre en œuvre une nouvelle fonctionnalité. Pour quelque raison que ce soit bien, j'ai décider de la corbeille, peut - être ai-je écrit qu'il est mauvais, peut-être que j'ai changé d'avis au sujet de la mise en œuvre, quoi que ce soit. Tout ce que j'ai, est de revenir à une ancienne version de SVN à la place de de revenir manuellement chaque fichier en question.
Subversion n'est pas. Mais la source de contrôle.
Peu importe si vous êtes un développeur ou un groupe de développeurs, vous devez effectuer les opérations suivantes avant de commencer à coder RIEN:
Utiliser quel que soit le système que vous aimez, git,
SVN, Mercurial. Il n'est pas question que
longtemps que vous savez comment l'utiliser.
système de documentation. L'utilisation d'un Wiki
ou un trac, ou tout autre système
vous savez comment l'utiliser.
Make, ANT, Maven, ou n'importe quel autre
le système vous savez comment construire.
Ne pas coder une seule ligne de l'application principale jusqu'à ce que vous avez fait ces quatre
Je recommande fortement de contrôle de code source quelle que soit la taille de l'équipe. J'ai eu trop de la fin des sessions de nuit où je me suis cassé le code et ne pas avoir le contrôle de code source pour les anciennes versions de travail.
De Contrôle de Version peut avoir les avantages suivants:
Mais là encore, il a aussi ses inconvénients si vous n'avez pas de choisir un bon
Quand je veux aller dans les magasins, je prends ma voiture pour le transport du shopping à la maison. Il est pas nécessaire de mettre du gaz dans ma voiture. Je pouvais choisir de pousser la voiture à la place, mais pourquoi voudrais-je?
De même avec les choisissant de ne pas utiliser le contrôle de version....
OUI!
Désolé de crier 🙂
De contrôle de Version n'est pas seulement utile pour la restauration de versions. Il vous donnera beaucoup de sécurité contre le déploiement d'anciennes versions de fichiers ou d'écraser accidentellement des versions plus récentes avec les anciennes versions, etc.
Une chose que je suis seulement maintenant à s'habituer à ce qui est vraiment utile est la capacité de la direction générale et de fusionner les différentes versions. Si vous disposez d'un délai à venir mais vous travaillez sur une nouvelle fonctionnalité qui n'est pas prêt pour le prime time, vous pouvez simplement branche avant de vous commencé l'ajout de cette fonctionnalité. Créer un livrable version sans cette caractéristique, et fusionner ces deux après la date limite passe sans problèmes.
Bien sûr, le contrôle de version est nécessaire, même pour un homme de projet.
La possibilité d'enregistrer des contextes et pas seulement les changements dans le code, c'est la grande chose que de la source de contrôle de fait, vous passer de la "fichier et ce qui a changé dans la ligne de bla" à "j'ai ajouté une nouvelle option pour le faire ..." qui est vraiment précieux.
Ne m'écoutent pas, si il y a un excellent article qui rands a écrit à propos de ce
La Capture Du Contexte
OUI, mais uniquement pour les développeurs des équipes où la taille est > 0
Lorsque j'ai arrêté mon IDE/éditeur de texte/whatever et de revenir le lendemain pour comprendre que je veux annuler la dernière boneheaded erreur, la Source de contrôle est là pour moi, de tomber sur le dos, ou de l'utilisation de la direction générale et effectuer quelques sauvages expérience sur mon code. Sans contrôle de code source je ne peux pas faire ces choses si librement.
Pour les équipes de taille > 1. vous disposez d'une sauvegarde centrale, vous avez de l'équipe échelle de l'annuler, il est plus facile (possible) de travail distribué, qui, lorsque la taille de l'équipe est supérieur à 1, c'est vraiment ce que vous faites de toute façon n'importe comment loin de vos coéquipiers sont.
De Contrôle de Version OUI, vous avez toujours besoin d'effectuer le contrôle de version.
SVN? non.. moi, j'utilise Git.
Je dirais pour git, pour deux raisons principales
[ces sont apparemment vrai pour Mercurial ainsi. Ils sûr que le diable n'est pas si facile pour subversion.]
Tout le monde qui est en train de dire que le contrôle de source de 1-2 développeurs est un must est complètement, complètement à droite. Faites-nous confiance 🙂
De retour au collège, j'ai eu un professeur qui nous a fait utiliser le contrôle de source. Nous avons tous des coups de pied et a crié, parce que CVS semblait trop compliqué et sonnait comme overkill pour les projets des étudiants. Finalement, nous sommes tous venus autour, et même pour les projets simples à partir de là, je voudrais de les mettre tous dans le contrôle de source. J'ai continué à ce jour, et ont sauvé de moi-même, de nombreuses heures de frustration.
Simple réponse OUI.
De ne pas réitérer, mais il ne peut pas être dit assez. Vous DEVRIEZ AVOIR le contrôle de source. Subversion est ridiculement facile et pratiquement zéro frais généraux, une fois le programme d'installation. Littéralement, ne devrait pas prendre plus de 5 à 20 minutes pour l'installation. Vous avez d'autres choix, comme GIT. Donc, juste en choisir un, et de mettre votre source là - fin de la réponse. 🙂
Il y aura une certaine perte de temps lors de la configuration du système et instuct les autres développeurs - surtout s'ils ne sont pas familiers avec versioncontrol (ou la subversion dans le détail).
Mais les avantages d'être en mesure de revenir à une précédente (de travail) de la version et de la possibilité de faire une simple comparaison des fichiers archivés seront plus que la peine.
Le plus gros problème est que les récompenses -comme la plupart des choses - venir après le "dur travail". 🙂
Remarque, d'un autre, mais plus léger de la solution peut être enabeling de l'Ombre "Copier" sur Windows, si c'est votre système d'exploitation serveur (bien que je pense que ce ne sera pas). L'avantage de cette est que vous ne serez pas déranger votre co-développeurs de l'apprentissage de la subversion, mais vous serez en mesure de revenir à une version antérieure si nécessaire...
De contrôle de Version devrait être la première chose que vous pensez à ce sujet lors du démarrage d'un projet. La deuxième est automatique construit, la troisième est de tester, la quatrième est l'intégration de vos tests avec vos constructions.
VSS est bien, mais mucho dinero.
essayer mercurial (hg) au lieu de svn
Oui, si vous êtes un développeur professionnel, alors vous devez absolument utiliser le contrôle de version!
vous avez besoin de contrôle de la source si au moins UNE des conditions suivantes est remplie:
1) il n'y a plus d'UN développeur
2) le projet est plus que les locations de longue
3) le projet a plus de 5000 lignes de code
donc, si vous êtes deux personnes que vous avez besoin pour utiliser le contrôle de version. Aussi, si vous êtes seul, mais votre projet d'atteindre une pas anodin la complexité... vous avez besoin de contrôle de version!
J'ai toujours utilisé une sorte de contrôle de version pour mes projets privés (#programmeurs == 1), au début tout des copies avec des nombres, plus tard, RCS, puis CVS, puis à la subversion. Les avantages de voir ce que vous avez modifié à quel moment et pourquoi pas de prix. Donc, si le contrôle de version est bonne pour un seul programmeur, il ne peut pas être pire pour une équipe de personnes.
Je suis juste jeter ce là-bas, mais je crois que PERFORCE est gratuit
pour un maximum de 2 développeurs. Ne sais pas combien il est facile à mettre en place.
Je suppose que vous voulez quelque chose qui est facile à configurer et à utiliser.
À l'origine du rcs outil est toujours là et fonctionne encore (sur unix et windows/dos) est peut-être la plus simple de ces outils, c'est pourquoi je le recommande pour les deux hommes de l'équipe de travail sur le même système (par exemple, le même bureau, le même serveur de fichiers ou un hôte unix). Il ne vaut entrer dans un modèle client/serveur comme subversion si vous travaillez dans des environnements distincts.
De contrôle de la Source vous donnera la paix de l'esprit. Je suis un mISV et de la perte de mon disque dur système plus tôt cette semaine. Mon code est dans plusieurs dépôts Subversion. Je venais de finir de ré-organiser le code, pour que je puisse simplement vérifier et s'en aller.
Je suis en attente pour le nouveau disque dur pour arriver. J'ai la paix de l'esprit que lorsque le nouveau disque dur est ici, je vais être en mesure de continuer à améliorer mon produit à un endroit où j'ai laissé la.
Oui, la source de contrôle est un must.
- Je utiliser Vault Sourcegear qui est gratuit pour un seul développeur.
Même avec une petite équipe, de contrôle de version comme Subversion est importante, non seulement pour être en mesure de comparer entre les révisions, mais aussi de revenir à un précédemment version de travail.
Mais tout cela vient avec qui ajoute à la complexité. Au lieu de sauvegarder le code, il doit être vérifié dans le système. Chaque version majeure du système de contrôle dispose d'outils pour vérifier facilement le code, et ils seront nombreux à s'intégrer directement aux IDEs. Toutefois, cela ne change pas le fait qu'il ya des étapes supplémentaires qui doivent être prises lors de l'enregistrement de fichiers de code. Il existe une surcharge en plaçant le code dans un système de contrôle de version, mais d'avoir du code qui fonctionne pour revenir à quand un problème se produit peut compenser cette surcharge.
De contrôle à la Source ne vous coûte rien, mais le temps de sa mise en place. C'est juste un no-brainer.
Oui, même si vous êtes la seule personne de la source de contrôle est un must. Bien sûr, vous ne serez pas en utilisant de contrôle, qui est de travailler sur les fichiers, mais d'avoir la capacité de rôle si vous faites une grosse erreur dans votre code est vraiment pas sorcier.
Est Visual SourceSafe une option? Je suis un simple programmeur et ont été en l'utilisant comme un repositry pour la dernière sans problèmes, mais j'entends souvent parler d'histoires d'horreur. Est-il vraiment si mauvais?
De Contrôle à la Source OUI.
La Subversion N'
Subversion est approprié pour vraiment complexe trucs qui ont besoin de gérer la ramification VRAIMENT bien. Sinon c'est pas la peine de faire l'effort d'apprendre et de le maintenir.
Il y a plein d'autres plus simples de contrôle de la source à une petite taille (personnellement, je recommande PerForce)
BTW, je dirais que la Création d'un système de construction est plus important que le contrôle de version.
Maintenant, avec si peu de gens qu'il EST possible de gérer de contrôle à la source par la subdivision de vos fichiers de travail avec soin, mais cela ne vous donne pas de contrôle de version (qui est essentiellement construite automatiquement dans n'importe quel contrôle de code source, vous trouverez)
À tout le moins, vous devez être en mesure de regarder en arrière et trouver une version de votre fichier de quelques semaines.
Subversion n'est pas excessif pour petits groupes et de, mais ne devrait pas être considéré comme un remplacement pour une bonne gestion de projet. Longue histoire courte, si les gens n'ont pas un calendrier et une bonne communication, l'utilisation du contrôle de version n'est pas beaucoup mieux de ne pas utiliser et peut causer plus de problèmes qu'elle vise à résoudre. Les Questions que vous devez répondre, tandis que la mise en œuvre de contrôle de version:
Considérer ce cas courant où des correctifs ont été appliqués à certains instable de la fonctionnalité "Une" au cours d'une période de quelques mois, disons. Le développeur(s) édité plusieurs fichiers pendant ces plusieurs tentatives et bien que la fonctionnalité de "A" a obtenu fixe, mais une autre fonctionnalité "B" s'est cassé. C'est généralement réalisée après un certain temps et il ne peut être rappelé que la fonctionnalité "B" a été de travailler à un point de temps. En présence de contrôle de version tous un développeur(s) a/ont à faire est d'aller à travers les révisions précédentes et de la portée de la révision(s) qui a éclaté "B" et simplement annuler ces pièces. À l'aide d'un simple diviser pour régner pour atteindre l'erreur versions qui le rend si rapide (si la révision en cours est de 2000, vérifiez 1000 - si ça fonctionne, puis vérifier 1500 ...).
En l'absence de contrôle de version, le développeur(s) a/ont au moins pense frais sur la façon de faire fonctionner à nouveau et ainsi avoir à passer des frais de temps sur quelque chose pour laquelle le temps a passé. Maintenant, cela peut être l'un de l'enfer beaucoup de fonctionnalités du projet et même le seul développeur peut oublier les spécifications exactes. Donc, une spécification de recherche est nécessaire et ce pas?
J'ai souvent senti comme à la boxe certains membres de la expérimentés les développeurs dans la tête qui n'a pas utiliser le contrôle de version dans un projet, ils ont travaillé et plus tard, j'ai eu à appliquer quelques corrections sur le même projet. Un exemple développeur a utilisé pour se sentir paresseux de la configuration de l'SVN et de le maintenir et d'ailleurs il ne serait pas me dire correctement lorsque je lui demanderais exactement comment il travaillait (quand j'ai été affecté à un poste), parce qu'il serait occupé avec un autre projet.
La paresse est une commune de la faiblesse humaine. N'importe qui peut se sentir paresseux. Je parie que la plupart des gens se sentent paresseux ou plutôt irrité de réfléchir à quelque chose qui a déjà été fait dans les autres cas (absence de contrôle de version). Alors, laquelle est la mieux? Être paresseux avant ou être intelligent et paresseux par la suite.
J'ai codé pendant 15 ans à l'échelle de plusieurs emplois et n'a jamais perdu le code ou a eu un problème avec la gestion des versions jusqu'à ce que nous avons COMMENCÉ à utiliser une source de solution de contrôle où nous avons perdu des semaines de travail en un seul coup. Les frais généraux de l'utilisation du contrôle de version n'était qu'une perte de l'omi.
Je ne pense pas qu'il est nécessaire, cependant, je suis en train de faire pour la plupart des applications web pas des programmes complets. Je n'ai jamais travaillé sur la même page web comme un autre programmeur en même temps.
Je serais tenter d'être le premier à répondre NON. Il faut du temps pour apprendre à l'utiliser efficacement. Et il peut être source de confusion pour les utilisateurs. Rouler en arrière? La fusion des changements? être capable de direction de votre projet? ou assurez-vous que toutes ces choses que vous supprimez maintenant ne va PAS être perdu pour toujours? Son utile dans quelques cas seulement, et je ne suis pas sûr à 100% que les 10 minutes qu'il faut pour trouver SVN ou TortoiseSVN et de le télécharger, de + de 30 min pour en apprendre un peu plus sur l'utilisation en vaut la peine.
Otoh, que: Est. Votre. partenaire. *)&%$#. fou?
Nous avons plusieurs outils possibles pour l'utiliser au travail. Pas d'un large soutien, soit CVS ou SVN, mais plutôt une commerciale relative pour la plupart des choses..
J'ai utiliser tortoiseSVN sur mon pc pour gérer mes propres documents WORD et des feuilles de calcul, et je trouve que la FUSION de la capacité de aide vraiment les autres à modifier mes feuilles de calcul et de les envoyer de nouveau à moi. (J'ai tendance à faire de la fusion en enregistrant les différentes versions comme une feuille de calcul xml. )
ou pour sauvegarder les modifications apportées lorsque j'utilise un doc ou une feuille de calcul sur plus d'un PC.
Cependant de polémiquer sur ça ne fonctionne pas. Montrez-lui comment l'installer, et faire preuve d'un peu d'édition du même document. Ou de les laisser former eux-mêmes à logiciel de menuiserie.